Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Linux Software

McVoy on BitKeeper, Linus, and Perens 40

Joe Barr writes "The story of how BitKeeper has come to be Linus Torvalds' (and many other kernel hackers) tool of choice in maintaining the Linux development tree is worthy of a book. Here's the Cliff Note's version of McVoy's contribution to Linux kernel development, BitKeeper, and countless hours of flaming on the role of open source and proprietary software."
This discussion has been archived. No new comments can be posted.

McVoy on BitKeeper, Linus, and Perens

Comments Filter:
  • Question (Score:1, Funny)

    by Anonymous Coward
    What is a BitKeeper?
  • by Anonymous Coward on Monday January 27, 2003 @12:23PM (#5168086)
    char bitsafe;

    void SetBit(char bit)
    {
    if (bit != 0 && bit != 1)
    FatalError("bit must be 0 or 1");
    bitsafe = bit;
    }

    char GetBit()
    {
    return bitsafe;
    }
  • interesting (Score:5, Interesting)

    by Anonymous Coward on Monday January 27, 2003 @12:28PM (#5168120)
    McVoy seems very reasonable in this interview. He's a smart guy, and, like he says, a little insecure.

    However, it would be best if someone came up with a Free alternative to BitKeeper as quickly as possible.

    Proprietary source code management is a little too dangerous in my opinion. It gives the code owners unilateral power over your project, even if they don't choose to exercise it today, they might tomorrow. You might be forced someday to choose between accepting their new terms, or moving your project to a new system (which might take months of time).

    It's pretty stupid to choose your software ONLY on technical merit (the "best tool for the job" mentality that engineers and technical folks have). Remember that the license and the business model of the company offering the software might have a material impact on YOUR business someday!

    When your code is tied up inside of another company's product, it's best to stick with Free software if possible.
    • by j.e.hahn ( 1014 ) on Monday January 27, 2003 @12:50PM (#5168227)
      1) It doesn't matter what soource control system you use, you still own your own code. If the company making the source control product goes nuts, then you just have to abandon them.

      2) The best tool for the job mentality comes from long experience with inadequate tools. All too often people come along saying "Here use the screwdriver. I know you need a hammer, but at least my screwdriver is ethically pure." Open Source tools are a good thing. They are not always the best fit.

      3) Free software is NOT always the best option. Especially for large businesses which are concerned about the potential license taint and support issues. I love Free Software, but it's not always the right fit.

      4) There are 2 free alternatives to bitkeeper: CVS and Subversion. Learn them, use them.
      • by JimDabell ( 42870 ) on Monday January 27, 2003 @01:48PM (#5168518) Homepage
        It doesn't matter what soource control system you use, you still own your own code. If the company making the source control product goes nuts, then you just have to abandon them.

        Exactly. You have to put time & effort into evaluating other tools, learning whatever you decide upon, and transferring your code over to that system. Most of the time, you cannot transfer the repositories between different systems, only the current code.

        If the vendor is showing signs of "going nuts", it would be silly to start to use their tools. Some people would argue that the recent licensing silliness with bitkeeper is a danger sign, but I don't want to get into that argument.

        Free software is NOT always the best option.

        All other things being equal, I would disagree. All other things are not usually equal, however, so you have to decide on a case-by-case basis. A free alternative is always a good thing, even if you don't use it, it keeps the proprietary vendors on their toes.

        Especially for large businesses which are concerned about the potential license taint

        License taint? Your code is not a derivative of the version control system you use, there is no tainting issue. The common open-source licenses have no usage restrictions, unlike bitkeeper's license.

        and support issues.

        Open vs proprietary support issues have been discussed over and over. Companies support free software, companies support proprietary software. You have a choice of which companies you go to with open-source software, you don't with proprietary software. There's no issue here.

      • wtf? (Score:5, Insightful)

        by Ender Ryan ( 79406 ) on Monday January 27, 2003 @02:01PM (#5168587) Journal
        3) Free software is NOT always the best option. Especially for large businesses which are concerned about the potential license taint and support issues. I love Free Software, but it's not always the right fit.

        "potential license taint"? What are you talking about? There is no potential license taint with free software. It is distributed under certain terms, if you want to incorporate the software in your own, then you have to either accept those terms or license a proprietary version of said software, if possible. With proprietary software, the only option you have is the latter.

        Stop spreading this bullshit FUD about license tainting; it's absolutely ridiculous.

        You say you love free software, if so, then please understand what you are saying about it.

        • Re:wtf? (Score:3, Insightful)

          by The Bungi ( 221687 )
          With proprietary software, the only option you have is the latter.

          Actually, your choice there is not to buy the software. That's one little detail that people like yourself forget when they decry the evils of closed source.

          As with everything else in the real world, you vote with your hard-earned moolah.

          The extreme (let's screw ourselves because the tool/os/app we need is not 100% certifiably open source free-as-in-whatever) is problematic at best and stupid at worst.

          • Actually, your choice there is not to buy the software. That's one little detail that people like yourself forget when they decry the evils of closed source.

            What the fuck are you talking about? Of course you have that choice! WTF?

            With OSS, the equivalent choice is to not include that software in your own, but you can still use it, study it, look at it, etc. OSS software gives you equal + more choices than proprietary software -- integrating the software into your own according to OSS licensing terms/using it/integrating it and not distributing it(in which case you are not bound by any terms) OR getting a non-OSS/proprietary license from the authors of the software for you to use in your own proprietary product(if the authors are willing), whereas with proprietary software you cannot use it under any conditions without consent of the authors.

            The extreme (let's screw ourselves because the tool/os/app we need is not 100% certifiably open source free-as-in-whatever) is problematic at best and stupid at worst.

            Where the hell did I ever say that?

            Get a fuckin` clue...

      • by Anonymous Coward on Monday January 27, 2003 @02:27PM (#5168734)

        1) It doesn't matter what soource control system you use, you still own your own code. If the company making the source control product goes nuts, then you just have to abandon them.

        That's not the point, the point is your code is STORED INSIDE the product. So if you switch, you have to start from scratch on a new product. You don't just "abandon it" you have to pay time (i.e. money) to switch. This is true for any proprietary system.

        3) Free software is NOT always the best option. Especially for large businesses which are concerned about the potential license taint and support issues. I love Free Software, but it's not always the right fit.

        You love it so much that you spread lies about it? If you're not incorporating the Free software into your own product, there is no more license taint than using a proprietary system (in fact, there is less risk because freedom to use is guaranteed). And many Free licenses, such as BSD, "taint" your project only in the most minimal way, even if you distribute.

        So, let's see you ship a gratis copy of MS SQL server with each unit of your next product, and then let's talk about "license taint" (when you're through with the lawsuits of course).

        4) There are 2 free alternatives to bitkeeper: CVS and Subversion. Learn them, use them.

        Good advice, and let's add one more: IMPROVE them!

        • That's not the point, the point is your code is STORED INSIDE the product. So if you switch, you have to start from scratch on a new product. You don't just "abandon it" you have to pay time (i.e. money) to switch. This is true for any proprietary system.

          I don't follow your argument.

          OK, it's stored inside. But to eat your code completely they'd have to:
          1. switch off their product overnight giving you no notice to export your source / history
          2. delete all your working copies on developer machines
          3. delete all your daily backups of the working copies.
          If they can (legally) pull of the first you'll lose at your revision history but there's no way you're going to lose your source.

          If you're not incorporating the Free software into your own product, there is no more license taint than using a proprietary system

          The GPL has never (AFAIK) been tested in court and it's open to some interpretation - all the arguments about the definition of 'link'. That's why businesses are nervous about using it. IMO, it's up to the FSF to nail down the definition to make businesses happy.

          So, let's see you ship a gratis copy of MS SQL server with each unit of your next product, and then let's talk about "license taint" (when you're through with the lawsuits of course).

          But they provide MSDE, a redistributable SQL server core, specifically for that. The licence says:
          1. no Microsoft endorsement (c.f. Apache licence)
          2. may not sue Microsoft (i.e. no warranty c.f. any free software licence)
          3. may not use in a competitor to Microsoft Office.
          That's not too bad, is it?
      • I'm not joking. And don't call me Shirly.
        - Naked Gun

        or

        If I were joking I would say: "What do you do with an elephant with three balls? You walk him and pitch to the Rhino."
        - Hot Shots
      • There are more free SCM tools than CVS and subversion. Unfortunately most of them DON'T SCALE.

        Subversion and CVS both suffer from a single-repository design. A closer fit to (my understanding of) bitkeeper is 'arch'.

        (Disclaimer: I use arch and hack on a clone thereof called barch :})
      • There are 2 free alternatives to bitkeeper: CVS and Subversion. Learn them, use them.

        Actually, I just started using Arch, which has a learning curve, but which is Really Cool (tm).

        Distributed repositories, so I can code on the road or at home, and not worry about getting too out of sync.
    • by Brian Hatch ( 523490 ) on Monday January 27, 2003 @01:04PM (#5168286) Homepage Journal
      The debate between using the best tool for the job, vs using the best Open Source equivalent is going to be around forever. Here are some of my completely random thoughts:

      • When you choose an Open Source project and it has deficiencies, you can talk with the developers to explain what needs fleshing out. If you can code, then you can work on this yourself. In the end, you help create a better product that may be more appropiate for a wider audience. It may be painful in the process, however.

      • When you are told you must have certain functionality that is not available in an Open Source product, make sure that the requirements are not artificial. When someone requires you have your document in some proprietary format, you can supply it in something open and they may never know the difference. Write your "Word Docs" in OpenOffice. Make your presentation in HTML and run it with a web browser. Question any requirements that seem to be based on the preconcieved notions of the requestor.

      • When functionality of an Open Source product is close but below its proprietary equivalent, do remember that "usability" is a factor of what you can do now, and what you can do later. The Open Source product will be available in it's current incarnation freely forever. (And later versions will likely continue to be developed as well.) The proprietary product may not be around tomorrow, it's license may change, or they may hold your work for ransom, and you have no control. You will likely find the product depricated forcing a costly upgrade at some point - that's the way the vendor continues to get income.

      • When you simply must have a given set of functionality that is not available with Open Source software, and you do not have the ability to work with developers to achieve it, use the proprietary product reluctantly. Stay abreast of changes to the Open Source products available. Do your best to keep as much available outside the proprietary application so you can extract it and put it into something Open Source when available down the road.

      • The proprietary product may not be around tomorrow, it's license may change, or they may hold your work for ransom, and you have no control.

        This argument comes up quite a bit and I don't understand it.

        If I buy an indefinite licence of fookeeper and use it to control my source, how can I be stopped from using my own repository? If the fookeeper authors deprecate it and stop me from buying more licences, I can use my old licence to extract revision history from fookeeper and feed it into my new revision control software.

        If I buy a year's licence for fookeeper and decide not to renew it, I have plenty of notice to extract revision history from it and feed it into my new software before it stops working.

        If I'm a good developer and back up my working copy daily then I'll always have a recent snapshot of my source anyway.

        How could the software not be around tomorrow? How could they 'hold my work for ransom'? Why don't I have control?

        Ta.
        • If you buy a bitkeeper licence, then presumably you're fine. This debate is about the no-cost licence.

          That licence gives lm the right to change the licence in the future and to revoke your licence. He has demonstrated publicly that he is very willing to do this to people who annoy him. The licence is essentially the "don't piss off larry" licence.

          lm insists that since he's allowing people to use it at no charge, he is able to impose whatever conditions he wants. That may or may not be morally or legally fair. All I'm suggesting is that it's a bad idea to take him up on the offer.

          I have plenty of notice to extract revision history from it and feed it into my new software before it stops working.

          No, you may not. For example, with no warning, Larry announced that people who have sent patches to arch, cvs, or subversion are not allowed to use bk. If you're part-way through a project that depends on it, you're screwed.

          Even if you don't fit into this category, then I think you ought to be concerned that you might be next.

          Suppose RMS was always changing the GPL to ban Microsoft, or Amazon, or whoever he dislikes this week. Even though I'm not at Microsoft, it would make me pretty worried about the potential future changes.

          If I'm a good developer and back up my working copy daily then I'll always have a recent snapshot of my source anyway.

          Sure, but merely having your working copy is a poor compensation for losing your change history. If that was all you wanted, and you made backups every day, you wouldn't need a CM system at all.

          If you want a proprietary system, look at BK: it's good technology, although not as novel as lm says it is. However, if you want to do free software, I think it's a pretty poor idea.
    • Re:interesting (Score:3, Informative)

      by rplacd ( 123904 )
      bitkeeper uses SCCS as its underlying layer, sort of similar to how CVS uses RCS for the files. There are (free) SCCS tools available, so you can probably pull your code out of bk if you feel the urge. Also, as I understand it, if the company ever dies, bk goes open source. Not so proprietary now, is it?

      bk's a great solution to a problem not really addressed by anyone else. Personally, I hope it doesn't go away.

      I don't use it, by the way. I'm thinking of writing a webdav client for a non-Unix operating system, and extending it to support subversion. The bk freebie license prevents me from using bk while working on a competing product.
  • A bit biased. (Score:3, Interesting)

    by wzm ( 644503 ) on Monday January 27, 2003 @12:50PM (#5168229) Homepage

    As most people will not read the article, and just go to the comments, I feel that I should point this out. This is an interview with the person behind BitKeeper. His opinions are (obviously), biased, and should be taken with a grain of salt.


    Possibly because of that, he comes across as a reasonable individual, although there was one issue which stuck out in my mind. If he advocated that Sun open source SunOS, stating that it was a feasible option, why hasn't he done the same for BitKeeper?

    • Re:A bit biased. (Score:1, Informative)

      by Anonymous Coward
      If he advocated that Sun open source SunOS, stating that it was a feasible option, why hasn't he done the same for BitKeeper?

      Sun can still sell hardware. He can't

    • Re:A bit biased. (Score:4, Informative)

      by RocketJeff ( 46275 ) on Monday January 27, 2003 @02:33PM (#5168768) Homepage
      If he advocated that Sun open source SunOS, stating that it was a feasible option, why hasn't he done the same for BitKeeper?
      Simple reason - Sun doesn't make any (or so little it doesn't matter) money selling SunOS/Solaris - it makes its money selling the hardware that runs SunOS/Solaris. Even if they Open Sourced it and people ported it to every non-Sun computer in existance, they still wouldn't lose too many sales - and they'd gain the fixes/enhancements made for free by the Open Source developers.

      BitKeeper, otoh, sells software. If they Open Sourced it, they'd loose a lot (most) of the sales of their ownly product.

      Different companies, different products, different focus.

  • There are a ton of issues wrapped up in this whole bitkeeper saga:
    • Proprietary vs Open
    • Cost vs Free
    • Freedom vs Artificial Restrictions
    • 'Best Tool for the Job vs Ideal Choice
    • Long Term Investment vs Rapid Development
    And that's just scratching the surface. There are valid reasons for choosing one path or another. This article is enlightening in that we now have a face and series of reasons as to why McVoy chose to implement Bitkeeper as a company with a business plan that closely resembles common closed source companies.

    We also have some enlightenment as to how and why Linus chose to move to bitkeeper.

    McVoy said, "Hey, Linus, let's work out the system for the 'best tool' to help you do your work." They came up with a rough specification, and McVoy has used that data specifically to create a profitable product, which (he claims) Linus started using spontaneously. The fact that it's almost exactly what Linus needs is by design from the start.

    People who are up in arms about it being developed as proprietary software are complaining about the wrong thing. McVoy used his connections to gather information for a product which turned out to be a killer app in the area of source management. The fact that he's letting open source people use it for free is no more philanthropic than Microsoft donating software to universities at a reduced rate - it's another business decision.

    What open source advocates ought to be up in arms about is, "Why don't we have an open source product that rivals bitkeeper in its scalability?" The answer is that we've long had tools that were 'good enough', and we've never had a project nearly as large and complex with so many developers and scalability issues as Linux itself has that has justified 3 years of its own development.

    We've just added another crutch to the tired old horse that is source management, and said, "We'll get around to replacing the horse someday, but right now I only need feature X so I can complete feature Y on the real project - I'm not going to waste my time building tools."

    As far as the constant 'best tool' vs 'ideal world' choice goes, the idea that one should use the best tool for the job regardless of ideology is the same argument that says, "It's ok that my t-shirt was made by a 12 year old in malaysia, who works for 12 hours a day and barely gets enough to eat for the pay." There are good reasons for voting with your money, and voting with your use and advocacy of obviously inferior and possibly more expensive (in time, materials, money, etc) tools and products.

    However, a good tool can make one significantly more productive, especially if there's no learning curve associated with the use of that tool. I'd have no problem learning that, say, Red Hat uses MS Windows and Office inhouse for its sales force and secratarial staff. They probably don't, but if they did they'd have to give little or no training to new hires, increasing their immediate productivity.

    The reverse is also true, in many circumstances though. Investing time and money in training those employees can have long term payoffs - such as increasing the number of people in the world who can use such systems. It took Linus quite some time to come back up to his normal slow speed when he started trying out bitkeeper - but reports indicate that the investment has paid off, and he is now much more able to handle the load at a faster rate.

    Remember - this is just a scratch of the surface, and the fact is that these discussions are largely subjective and ideological. First be true to yourself. If you can't, in good conscience, use bitkeeper, then good for you. If you find you're more productive, and that's worth the ideological tradeoff, then congradulations on making that choice, knowing why you made that choice, and defending your choice as right for you. If you don't see it as a good tradeoff, then good for you for sticking to your guns - but don't gun down others because of your beliefs. They are not inferior - they simply have different values and priorities, and if you don't think they have the right to choose, then your closed mind is doing the worst damage to open source that can be done today.

    -Adam
  • by sohp ( 22984 ) <snewton.io@com> on Monday January 27, 2003 @05:24PM (#5169909) Homepage
    My favorite quote from the article:

    McVoy's first estimate was that he could create BitKeeper in six months, working by himself. The number of programmers increased to two, then four, then eight. The time grew from six months to three years.

    For those of you keeping score, that's an overage of 48 TIMES the initial estimate. Even the NASA didn't do that bad with the ISS.
    • I wasn't keeping score, but you may want to contact Larry and offer your uber-geek madz coding skills. It's obvious you can develop something like BK in time and under budget every time - otherwise you wouldn't possibly think about criticizing them, let alone post your criticism.

      Even the NASA didn't do that bad with the ISS.

      Maybe "the NASA" has a good job for you. I hear they're looking for volunteers to man the next Voyager mission.

      Remember to send postcards.

      • I never claimed I could flawlessly develop on time and within budget, but then, I wouldn't suggest that a single individual can develop a distributed, scalable, multiuser SCM in six months. Perhaps I wasn't clear: 8 people for 3 years is a fine scale for what BitKeeper is -- it was the initial estimate that ought to have been run out of town on a rail. That kind of estimation is at best an unprofessional commitment to the impossible. There's a term for projects that start out with those kinds of unrealistic promises, that every developer dreads: Death March.

        Personally, if someone tried to hire me to develop a new SCM tool with the scope of BitKeeper in six months by myself, I'd kindly excuse them from my office, no matter how much they offered.
        • RTFA. That's hardly an IT department sponsored kinda project where you can sit down and give the users an estimation after you've finished writing the requirements document and the high-level design.

          Your criticism is valid in a case like that, but hardly applicable to BK. If you must make a comment about how much someone sucks because they pooped the timeline, find another project.

  • by Anonymous Coward

    According to this report [isec.pl] (repeated also on bugtraq), there is important security hole in Bitkeeper (found in November). Looking at the Bitkeeper pages [bitkeeper.com] I can't find any notification about the problem or the patch. In the Polish article [linuxnews.pl] the guy who found the vulnerability reports, that Larry McVoy just stopped replying to mails when they started discussing when the advisory should be published.

    Leaving the but itself alone, the lack of information on their web pages and the lack of the patch after the advisory was published is - especially when talking about distributed internet application - very disguisting. The lack of information what has changed from version to version is disguisting too.

    I backed bitkeeper in many discussions. No more.

The 11 is for people with the pride of a 10 and the pocketbook of an 8. -- R.B. Greenberg [referring to PDPs?]

Working...