Slashdot Mirror

kfogel writes "Two thumbs up, and maybe a tentacle too, on Version Control with Git, 2nd Edition by Jon Loeliger and Matthew McCullough. If you are a working programmer who wants to learn more about Git, particularly a programmer familiar with a Unix-based development environment, then this is the book for you, hands down (tentacles down too, please)." Read below for the rest of Karl's review. Version Control with Git, 2nd Edition author Jon Loeliger, Matthew McCullough pages 456 publisher O'Reilly Media rating Very good. reviewer Karl Fogel ISBN 978-1-4493-1638-9 summary Using the Git version control system for collaborative programming. There's a catch. You have to read the book straight through, from front to back. If you try to skip around, or just read the parts you feel you need, you'll probably be frustrated, because — exaggerating, but only slightly — every part of the book is linked to every other part. Perhaps if you're already expert in Git and merely want a quick reminder about something, it would work, but in that case you're more likely to do a web search anyway. For the rest of us, taking the medicine straight and for the full course is the only way. To some degree, this may have been forced on the authors by Git's inherent complexity and the interdependency of its basic concepts, but it does make this book unusual among technical guides. A common first use case, cloning a repository from somewhere else, isn't even covered until Chapter 12, because understanding what cloning really means requires so much background.

Like most readers, I'm an everyday user of Git but not at all an expert. Even this everyday use is enough to make me appreciate the scale of the task faced by the authors. On more than one occasion, frustrated by some idiosyncrasy, I've cursed that Git is a terrific engine surrounded by a cloud of bad decisions. The authors might not put it quite so strongly, but they clearly recognize Git's inconsistencies (the footnote on p. 47 is one vicarious acknowledgment) and they gamely enter the ring anyway. As with wrestling a bear, the question is not "Did they win?" but "How long did they last?"

For the most part, they more than hold their own. You can sometimes sense their struggle over how to present the information, and one of the book's weaknesses is a tendency to fall too quickly into implementation-driven presentation after a basic concept has been introduced. The explanation of cloning on p. 197 is one example: the jump from the basics to Git-specific terminology and repository details is abrupt, and forces the reader to either mentally cache terms and references in hope of later resolution, or to go back and look up a technical detail that was introduced many pages ago and is suddenly relevant again[1]. On the other hand, it is one of the virtues of the book that these checks can almost always be cashed: the authors accumulate unusual amounts of presentational debt as they go (in some cases unnecessarily), but if you're willing to maintain the ledger in your head, it all gets repaid in the end. Your questions will generally be answered[2], just not in the order nor at the time you had them. This isn't a book you can read for relaxation; give it your whole mind and you shall receive enlightenment in due proportion.

The book begins with a few relatively light chapters on the history of Git and on basic installation and local usage, all of which are good, but in a sense its real start is Chapters 4-6, which cover basic concepts, the Git "index" (staging area), and commits. These chapters, especially Chapter 4, are essentially a design overview of Git, and they go deep enough that you could probably re-implement much of Git based just on them. It requires a leap of faith to believe that all this material will be needed throughout the rest of the book, but it will, and you shouldn't move on until you feel secure with everything there.

From that point on, the book is at its best, giving in-depth explanations of well-bounded areas of Git's functionality. The chapter on git diff tells you everything you need to know, starting with an excellent overview and then presenting the details in a well-thought-out order, including an especially good annotated running example starting on p. 112. Similarly, the branching and merging chapters ensure that you will come out understanding how branches are central to Git and how to handle them, and the explanations build well on earlier material about Git's internal structure, how commit objects are stored, etc. (Somewhere around p. 227 my eyes finally glazed over in the material about manipulating tracking branches: I thought "if I ever need this, I know where to find it". Everyone will probably have that reaction at various points in the book, and the authors seem to have segregated some material with that in mind.) The chapter-level discussions on how to use Git with Subversion repositories, on the git stash command, on using GitHub, and especially on different strategies for assembling multi-source projects using Git, are all well done and don't shirk on examples nor on technical detail. Given the huge topic space the authors had to choose from, their prioritizations are intelligently made and obviously reflective of long experience using Git.

Another strength is the well-placed tips throughout the book. These are sometimes indented and marked with the (oddly ominous, or is that just me?) O'Reilly paw print tip graphic, and sometimes given in-line. Somehow the tips always seem to land right where you're most likely to be thinking "I wish there were a way to do X"; again, this must be due to the author's experience using Git in the real world, and readers who use Git on a daily basis will appreciate it. The explanation of --assume-unchanged on p. 382 appeared almost telepathically just as I was about to ask how to do that, for example. Furthermore, everything they saved for the "Advanced Manipulations" and "Tips, Tricks, and Techniques" chapters is likely to be useful at some point. Even if you don't remember the details of every tip, you'll remember that it was there, and know to go looking for it later when you need it (so it might be good to get an electronic copy of the book).

If there's a serious complaint to be made, it's that with a bit more attention the mental burden on the reader could have been reduced in many places. To pick a random example, in the "Branches" chapter on p. 90, the term "topic branch" is defined for the first time, but it was already used in passing on p. 68 (with what seems to be an assumption that the reader already knew the term) and again on pp. 80-81 (this time compounding the confusion with an example branch named "topic"). There are many similar instances of avoidable presentational debt; usually they are only distractions rather than genuine impediments to understanding, but they make the book more work than it needs to be. There are also sometimes ambiguous or not-quite-precise-enough statements that will cause the alert reader — which is the only kind this book really serves — to pause and have to work out what the authors must have meant (a couple of examples: "Git does not track file or directory names" on p. 34, or the business about patch line counts at the top of p. 359). Again, these can usually be resolved quickly, or ignored, without damage to overall understanding, but things would go a little bit more smoothly had they been worded differently.

Starting around p. 244 is a philosophical section that I found less satisfying than the technical material. It makes sense to discuss the distinction between committing and publishing, the idea that there are multiple valid histories, and the idea that the "central" repository is purely a social construct. But at some point the discussion starts to veer into being a different book, one about patterns for using Git to manage multi-developer projects and about software development generally, before eventually veering back. Such material could be helpful, but then it might have been better to offer a shallower overview of more patterns, rather than a tentative dive into the "Maintainer/Developer" pattern, which is privileged here beyond its actual prominence in software development. (This is perhaps a consequence of the flagship Git project, the Linux kernel, happening to use that pattern — but Linux is unusual in many ways, not just that one.)

The discussion of forking and of the term "fork", first from p. 259 and reiterated from p. 392, is confusing in several ways. It first uses the term as though it has no historical baggage, then later takes that historical baggage for granted, then finally describes the baggage but misunderstands it by failing to distinguish clearly between a social fork (a group of developers trying to persuade users and other developers to abandon one version and join another), which is a major event, and a feature fork (that is, a branch that happens to be in another repository), which is a non-event and which is all that sites like GitHub mean by forking. The two concepts are very different; to conflate them just because the word "fork" is now used for both is thinking with words, and doesn't help the reader understand what's going on. I raise this example in particular because I was surprised that the authors who had written so eloquently about the significance of social conventions elsewhere would give such an unsatisfactory explanation of this one.

Somewhat surprisingly, the authors don't review or even mention the many sources of online help about Git, such as the #git IRC channel at Freenode, the user discussion groups, wikis, etc. While most users can probably find those things quickly with a web search, it would have been good to point out their existence and maybe make some recommendations. Also, the book only covers installation of Git on GNU/Linux and MS Windows systems, with no explicit instructions for Mac OS X, the *BSD family, etc (however, the authors acknowledge this and rightly point out that the differences among Unix variants are not likely to be a showstopper for anyone).

But this is all carping. The book's weaknesses are minor, its strengths major. Any book on so complicated a topic is bound to cause disagreements about presentation strategy and even about philosophical questions. The authors write well, they must have done cubic parsecs of command testing to make sure their examples were correct, they respect the reader enough to dive deeply into technical details when the details are called for, and they take care to describe the practical scenarios in which a given feature is most likely to be useful. Its occasional organizational issues notwithstanding, this book is exactly what is needed by the everyday Git user who wants to know more — and is willing to put in the effort required to get there. I will be using my copy for a long time.

Footnotes

[1] One of my favorite instances of this happened with the term "fast-forward". It was introduced on p. 140, discussed a little but with no mention of a "safety check", then not used again until page 202, which says: "If present, the plus sign indicates that the normal fast-forward safety check will not be performed during the transfer." If your memory is as bad as mine, you might at that point have felt like you were suddenly reading the owner's manual for an early digital wristwatch circa 1976.

[2] Though not absolutely always: one of the few completely dangling references in the book is to "smudge/clean filters" on p. 294. At first I thought it must be a general computer science term that I didn't know, but it appears to be Git-specific terminology. Happy Googling.

[3] (This is relegated to a floating footnote because it's probably not relevant to most readers.) The book discusses other version control systems a bit, for historical perspective, and is not as factually careful about them as it is about Git. I've been a developer on both CVS and Subversion, so the various incorrect assertions, especially about Subversion, jumped out at me (pp. 2-3, p. 120, pp. 319-320). Again, this shouldn't matter for the intended audience. Don't come to this book to learn about Subversion; definitely come to it to learn about Git.

[4] As long as we're having floating footnotes, here's a footnote about a footnote: on p. 337, why not just say "Voltaire"?

[5] Finally, I categorically deny accusations that I gave a positive review solely because at least one of the authors is a fellow Emacs fanatic (p. 359, footnote). But it didn't hurt.

You can purchase Version Control with Git: Powerful tools and techniques for collaborative software development from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

kfogel writes "Asheesh Laroia now has two GPG different keys with the same short ID (70096AD1) circulating on keyservers. One of them is an older 1024-bit DSA key, the other is a newer 4096-bit RSA key. Oops. Asheesh argues that GPG's short IDs are too short to be the default anymore — collisions are too easy to create: he did it on purpose and openly, but others could do it on purpose and secretly. More discussion (and a patch by dkg) are in this bug report."

kfogel writes "Karen Sandler (a lawyer at the Software Freedom Law Center) and Mike Tarantino (a professional musician) are getting married in May. They've sent out the coolest wedding invitation ever: a beautifully packaged flexidisc record where the invitation itself is the record player. The song was written by Mike, is performed by Karen and Mike together, and FTW is released under a Creative Commons Attribution-ShareAlike license. The person who designed the invitations — a friend of the couple's — has blogged about it."

kfogel writes "The Apache Subversion project has just had to remind one of its corporate contributors about the rules of the road. WANdisco, Inc was putting out some very odd press releases and blog posts, implying (among other things) that their company was in some sort of steering position in the open source project. Oops — that's not the Apache Way. The Apache Software Foundation has reminded them of how things work. Meanwhile, one of the founding developers of Subversion, Ben Collins-Sussman, has posted a considerably more caustic take on WANdisco's behavior."

kfogel writes "Canonical has just fully open-sourced the code to Launchpad. Although we'd said earlier that a couple of components would be held back, we changed our mind. All the code has been released under the GNU Affero General Public License, version 3. 'Canonical will continue to run the Launchpad servers, taking care of production and deployment issues; opening up the code doesn't mean burdening the users with all of that stuff. At the same time, we'll institute processes to shepherd community-contributed code into the system, so that people who have ideas for how to improve Launchpad can quickly turn these ideas into reality.'"

sciurus0 writes "As the open source version control system Subversion nears its 1.5 release, one of its developers asks, what is the project's future? On the one hand, the number of public Subversion DAV servers is still growing quadratically. On the other hand, open source developers are increasingly switching to distributed version control systems like Git and Mercurial. Is there still a need for centralized version control in some environments, or is Linus Torvalds right that all who use it are 'ugly and stupid'?" The comments on the blog post have high S/N.

chromatic writes with the review below of Writing Perl Modules for CPAN, which explains at a level "between novice and intermediate user" (and in a minimum of space) how to contribute to Perl's own Library of Alexandria. Writing Perl Modules for CPAN author Sam Tregar pages 288 publisher Apress rating Recommended. reviewer chromatic ISBN 159059018X summary A guide to the use and production of Perl modules, from start to finish, in C and in Perl. The Scoop

Besides Perl's abilities as a rapid development language, it's widely believed that the CPAN is its most valuable feature. This network of freely distributable code allows competent developers to achieve great heights of productivity, reusing the work of a generous community of programmers.

Of course, just as some will argue that Perl's copious documentation (spread over two thousand pages) is not immediately obvious to beginners, neither is how to use and even to contribute to the CPAN. For every coder who's successfully published a module, how many more would jump at the chance? How many registered CPAN authors would like to improve their skills?

With that audience in mind, Sam Tregar's Writing Perl Modules for CPAN plants itself firmly in the gap between novice and intermediate user. While much of the book presents information present in a multitude of FAQs, manpages, and the bittersweet experiences of those of us who did things the hard way, he's collected much knowledge into a short and readable guide.

What's to Like?

Tregar starts by describing the history and usage of the CPAN itself. This includes the three most popular approaches to building modules: through the CPAN shell (including its configuration), by hand, and with ActiveState's PPM tool. Next, he explains module development in forty pages. This is pretty dense stuff for the intended audience and might require several passes by newer coders. Only after re-reviewing the chapter for this summary did I realize how much he covered. The next chapter covers design and style, from naming schemes to appropriate laziness through code reuse. It's more philosophical and more important.

The next two chapters cover bundling and submitting modules to the CPAN, as well as being a good author and maintainer. The general tone is quite similar to the impressive Open Source Development with CVS. While manpages usually describe the mechanics of making a distribution, for example, they rarely explain the reasons why things are done that way. As with previous chapters, several code examples illustrate the concepts under discussion.

After a brief chapter discussing a few very effective CPAN modules, Tregar dives into XS (the interface between Perl and C). In 60 pages, he describes just enough of XS and the Perl API to teach careful programmers how to be effective at extending Perl. This introduction compares favorably to the first few chapters of the new (and excellent) Extending and Embedding Perl. As expected in an overview, he provides links to more information. The writing and example style is clear enough that a decent coder with sufficient C knowledge should be able to write a Perl wrapper to a C library with relative ease.

The last two chapters describe Inline::C, an abstraction layer that makes XS much easier, and CGI::ApplicationC, a state machine framework for Perl CGI applications. It's not quite clear why the last chapter was included (besides Tregar's desire to see more CPAN modules extending CGI::Application), but it serves as an example of using and extending a CPAN module. Perhaps a future version of the book will elaborate further.

What's to Consider

The book's code samples are generally good. In the first half, they are all related parts of a larger project. The rest of the book moves away from this approach. Perhaps it would have been worthwhile to continue the theme, though the nature of the material makes it difficult to see exactly how to accomplish this.

Tregar also avoids the use of strictures and warnings in his code examples, claiming that they would make the examples too verbose. I disagree with the given reasoning -- teaching is the best time to enforce good habits, especially when encouraging the students to distribute their code to the world. This is a minor issue, though, as the code is readable and reasonable.

In the past few months, two projects have gained a great deal of momentum in Perl space. These are the CPANPLUS (disclaimer: I am contributing to this project and have contributed to CPAN.pm) and Module::Build. They may become the new standards, replacing CPAN.pm and MakeMaker as early as Perl 5.10. The book omits mention of these. This is understandable, given the time frame -- and the current tools will not be disappearing any time soon. Potential replacements for h2xs are described in a sidebar, though.

The Summary

This is a readable book. It took only a couple of hours to read (though I'm assuredly not the target audience), and is well packed with good advice. Fresher Perl programmers who aren't yet comfortable enough with packages and interfaces will get the most benefit, but there's plenty of information for intermediate hackers as well.

Table of Contents

1. CPAN
2. Perl Module Basics
3. Module Design and Implementation
4. CPAN Module Distribution
5. Submitting Your Module to CPAN
6. Module Maintenance
7. Great CPAN Modules
8. Programming Perl in C
9. Writing C Modules with XS
10. Writing C Modules with Inline::C
11. CGI Application Modules for CPAN

You can purchase Writing Perl Modules for CPAN from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

C. Michael Pilato writes: "This overheard while eavesdropping on announce@subversion.tigris.org: Gentle coders, The ever-growing cadre of Subversion developers is proud to announce the release of Subversion 'Alpha' (0.14.0). Since we became self-hosting eleven months ago, we've gone through ten milestones. This milestone, however, is the one we've always been working towards; it's a freeze on major features for our 1.0 release. From here out, it's mostly bug-fixing. We hope this announcement will lead to more widespread testing; we welcome people to try Subversion and report their experiences on our development list and issue tracker." Subversion, a source control system akin to CVS, has been in the works for a couple of years now.

Managing software development is a job right up there with aircraft controller in the realm between fascinating and nerve-wracking. chromatic's latest review is of a book introducing one of the best known tools for managing the complexity inherent in such projects, Karl Fogel's Open Source Development with CVS.

Open Source Development with CVS author Karl Fogel pages 316 publisher Coriolis Open Press rating 8.5 reviewer chromatic ISBN 1-57610-490-7 summary More than a summary of CVS commands, Open Source Development with CVS is a study of how to organize and lead free software projects.

The Scoop Free software, the theory goes, is in a constant state of release. Instead of working in secret for years to produce a Grand Unified Model of Everything, then unleashing it on an unsuspecting world to the accompaniment of television commercials and full-page ads in trade magazines, development occurs in public view. That's aided, in no small part, by the convenience of CVS. So argues Karl Fogel in his introduction to Open Source Development with CVS. In that case, why not try it yourself?

Interspersed between CVS How-To chapters are Developer How-To chapters. For example, chapter 3 describes the author's theories on the entire Open Source process. That includes such common-sense advice as "Release something useful" and "Release something usable." There're plenty of examples to back up these ideas, drawn from the examples of large and popular open source projects.

What's to Like? CVS-specific chapters build on each other. Though 95% of the commands the average developer will ever use are covered in chapter two, the increasingly specific information just may come in handy someday. Though there's a price to pay for flexibility, the increased power it brings is worth it. If you've followed the examples and done some testing of your own, you'll have earned the title 'CVS Guru' by the end of chapter six.

Fogel's development essays take the pragmatic approach. Rather than preaching the One True Way to Do It, he analyzes several successful projects (Apache, the Linux kernel, and CVS itself being among the most prominent) and attempts to draw general principles from their histories. His overall philosophy seems to be "manage a few things well and strictly, and let your project evolve." With a good framework in place (both in your code and for your project administration), things will work smoothly and you'll be more likely to reap the benefits of the free software model.

Chapter eight gives troubleshooting tips. Fogel walks through the most common errors he's seen, doling out explanations and solutions with abandon. Chapter nine is a good reference, neatly summarizing CVS commands and files. Having completed the rest of the book -- and understanding the concepts, this section has the exact syntax at your fingertips.

What's to Consider? Though a complete reference on its own, occasionally the author defers discussion of some subjects in favor of referring to the Cederqvist manual accompanying a CVS source distribution. To be fair, these are often highly technical minutiae, but at 316 pages there is space for an expanded explanation of topics such as the RCS roots of CVS (knowing the source of CVS can help one to understand why some things are the way they are). Thankfully, there's information provided about the official FAQ and mailing lists where such data can be found. The Summary Beyond a comprehensive guide to using and administering CVS, Karl Fogel has written an easy-to-read guide on successful Open Source development. His practical focus and laid-back approach should prove workable for everything from pet projects to large undertakings. The author and Coriolis, the publisher, have also made chapters 2, 4, 6, 8, 9, and 10 available online at http://cvsbook.red-bean.com, under the GPL. Table of Contents

Purchase this book at ThinkGeek.

1. Why Open Source Development and CVS Go Together
2. An Overview of CVS
3. The Open Source Process
4. CVS Repository Administration
5. Designing for Decentralized Development
6. Advanced CVS
7. Building, Testing, and Releasing
8. Tips and Troubleshooting
9. Complete CVS Reference
10. Third-Party Tools That Work With CVS

1. CVS Maintenance and Development Today
2. GNU General Public License

Matt Braithwaite writes "Answering RMS's call for free documentation, Karl Fogel has written a book on CVS that is free (GPLed) and available online. (The paper version has additional non-free material.) " Also, edinator wrote to say that ORA has put the Using Samba text online. Some old news there, but, hey, some light figure for after eating turkey.

Matt Braithwaite writes "Answering RMS's call for free documentation, Karl Fogel has written a book on CVS that is free (GPLed) and available online. (The paper version has additional non-free material.) " Also, edinator wrote to say that ORA has put the Using Samba text online. Some old news there, but, hey, some light figure for after eating turkey.

pate writes "It looks like Red Hat has scooped up another free software name. According to this article, Havoc Pennington started work there yesterday. " He's the guy who does the weekly GNOME summaries, and is responsible for countless other Good Things(TM) in GNOME.

Karl Fogel writes "Ben Sussman and I have written a demo implementation of Ron Rivest's "Chaffing & Winnowing" algorithm, which we first heard about on Slashdot (it's now also mentioned in the July issue of Wired Magazine). Get the implementation or read Rivest's original paper The ciphertext output is designed to have an appearance closely resembling the packets discussed in Rivest's paper. I wouldn't use this package for your life-and-death, top-secret communications, but on the other hand it's a fun way to send semi-secret messages and use up a LOT of bandwidth in the process. Of course, it's GNU GPL'd, and -- as far as we know -- free of export restrictions. Enjoy!, -Karl Fogel "

Karl Fogel writes "Ben Sussman and I have written a demo implementation of Ron Rivest's "Chaffing & Winnowing" algorithm, which we first heard about on Slashdot (it's now also mentioned in the July issue of Wired Magazine). Get the implementation or read Rivest's original paper The ciphertext output is designed to have an appearance closely resembling the packets discussed in Rivest's paper. I wouldn't use this package for your life-and-death, top-secret communications, but on the other hand it's a fun way to send semi-secret messages and use up a LOT of bandwidth in the process. Of course, it's GNU GPL'd, and -- as far as we know -- free of export restrictions. Enjoy!, -Karl Fogel "

Karl Fogel writes "Ben Sussman and I have written a demo implementation of Ron Rivest's "Chaffing & Winnowing" algorithm, which we first heard about on Slashdot (it's now also mentioned in the July issue of Wired Magazine). Get the implementation or read Rivest's original paper The ciphertext output is designed to have an appearance closely resembling the packets discussed in Rivest's paper. I wouldn't use this package for your life-and-death, top-secret communications, but on the other hand it's a fun way to send semi-secret messages and use up a LOT of bandwidth in the process. Of course, it's GNU GPL'd, and -- as far as we know -- free of export restrictions. Enjoy!, -Karl Fogel "

Karl Fogel contributed this editorial on Microsoft, and why they are a problem. It is well written and makes a lot of good points very clear and you should read it carefully and think about it. This isn't the typical 'Microsoft Sucks' rant, read it with an open mind. Everything after this point is written by Karl Fogel Microsoft and the Rest of Us

Why do programmers hate Microsoft? After all, there's nothing wrong with trying to make money in the computer industry. Why should one company be vilified for doing what everyone else wishes they could do? Isn't Microsoft just trying to make a profit like the rest of us?

Not quite. Microsoft is certainly trying to profit, but not like everyone else: the missing ingredient is self-restraint. We all understand that for society to function, we must exhibit this quality in our personal lives, but sometimes we forget it is just as important in public life. Self-restraint means resisting temptation to push the envelope, because you recognize that the envelope was agreed on for good reasons.

Microsoft pushes the envelope by trying to control standards so it can lock in customers. It is not so much that it dislikes competing "fairly", as that it fears competing at all. Microsoft doesn't want any playing field, unless it can be be both referee and defending champion, and its relentless drive to be the the sole and only vendor of operating software for personal computers has brought it very close to that goal. Fortunately, our society long ago recognized that such snowballing accumulations of power were a weakness of open markets, and we enacted anti-trust laws to deal with the problem.

Some people don't think that anti-trust action is appropriate in this case. It's easy to regard Microsoft as blameless, merely using its market share the same way anyone would. It's also easy to believe Microsoft's claims that they're path-breakers at the leading edge of digital technology, whose creativity would be stifled by government over-regulation. These opinions, being so understandable, deserve detailed rebuttal.

Imagine this scenario: a regional supplier of electric current decides to get into the stereo business, and starts burning out its competitors' products by changing the rate at which it delivers alternating current. That would be intolerable, right? A clear case of using forced market share in one area to remove choice in another. But this is just what Microsoft has been doing! By controlling the operating system, it controls the substrate on which other software manufacturers are forced to build their products. They have no choice in the matter. And when threatening products come along -- Netscape Navigator, for example, which offers users a non-Microsoft window on the Internet, or Sun's Java programming language, which potentially offers an alternative platform to Windows 95 -- Microsoft responds like a classic monopoly: it tweaks the current.

As it happens, Netscape's grievances are being addressed by recent Justice Department actions, while Sun's plight prompted that company to bring a lawsuit against Microsoft. But neither should have been in these positions in the first place, and wouldn't have been if Microsoft didn't insist on abusing its position as a supplier of something very analogous to a public utility.

Nor are these isolated examples -- rather, they are the pattern which has always delivered Microsoft's success. Time after time Microsoft has leveraged an existing monopolistic base to gain control of a market which was being served perfectly well by an open, undominated standards process. Yes, new features and programming interfaces and standards pour forth from Redmond at a furious pace, but this is not because of customer demand. It is because Microsoft knows that by giving the rug sharp, unpredictable tugs from time to time, it can keep everyone -- especially software developers -- slightly off-balance, scrambling to keep up with a rate of change defined not by market pressures or genuine creativity, but by one company's need to hold all the cards no matter what the cost to consumer choice.

Anti-trust scrutiny is appropriate in this case for exactly the reasons those laws were originally enacted: a single company is in the position of being able to dominate an entire market, bringing competitors to their knees not through the superior quality of its products, but through the well-known dynamics of open markets, which, if unchecked, will always allow the larger to eat the smaller, and thus grow larger yet. For not only can the larger afford to keep fighting longer, it can also persuade third parties to choose its side or face the consequences. This latter ability is particularly insidious in an industry so dependent on cross-vendor standards to maintain interoperability.

It is tempting to shrug and say "Yes, but if it were not Microsoft in this position, it would be someone else. They are merely behaving in the only way they can, given their position as operating-system vendor." This is a seductive argument, but actually they could behave considerably better than they do. Other vendors have dominating market shares (Cisco Systems, for example, in network routers), but haven't acquired a reputation for forcing their proprietary standards on an unwilling public, nor for bending the public standards until no one knows what's public and what's proprietary. Microsoft is exceptional because it is never willing to give up control, even though it is very clear that no one else wants a single party to have control.

The Internet has a proven ability to settle on good, workable cross-platform standards by consensus. But Microsoft still tries to force us into doing things their way. Unlike other software vendors, they implement their own proprietary protocols before getting around to implementing public standards (i.e., ActiveX before Java, WINS before DNS, and does anyone even remember that document-embedding format they killed off?). This undermines perfectly good standards, even as it fails to establish Microsoft's way as a publicly available solution. The end result is that overall interoperability is made more difficult. Computer users face a choice between using only Microsoft products, or dealing with the headache of making their Microsoft products work with everything else. Don't think for a minute that this is not deliberate -- Microsoft knows full well the effects of what they do. That's why they do it!

Were it not for Microsoft's iron grip, we might well have long ago settled on a workable, public operating system standard that would allow developers to write truly portable software without worrying about whose monopoly they're buying into. This is not fantasy -- it has already happened in the Unix world, but Microsoft's influence has so far fatally hampered any possibility of an equally healthy standards process in the world of mainstream personal computers.

The notion that regulating Microsoft might stifle progress is also mistaken. If Microsoft were the source of any interesting progress in the computer industry, this might be a plausible argument. But let's briefly review some software history: what are the most important innovations of the last decade or so in computing? Off the tops of our heads, most of us would probably list the mouse, graphical user interfaces, networking in general and email in particular, certainly the World Wide Web. And how many of these bright ideas were first developed, or even brought to maturity, at Microsoft? Not a single one. Microsoft was actually a latecomer in all these areas, waiting until market pressure spelled out the future for them before acting.

Or perhaps you wonder if Microsoft has at least broken new ground in more esoteric areas, making contributions too technical to be noticed by the average computer user, but acknowledged among programmers? But you'd be disappointed again: there are none, at least none that would be called significant by anyone except a Microsoft employee. For all its treasure-laden coffers and glitzy, look-ma-we're-inventing-the-future public relations campaigns, it remains an essentially conservative company, watching others dive in while it tests the waters with its little toe, and rarely developing new technologies -- though often acquiring them by purchase: even MS-DOS, their first major product and hardly an innovation by anyone's definition, was not created in-house, but bought from outside.

What comedy, then, that Microsoft is so often referred to as an ``industry leader''. Its corporate policy is to follow, for which I suppose we should be glad, except that it's a particularly late and ungainly follower, throwing its weight around with little awareness that there are standards of good behavior even in a for-profit world.

There are indeed new things under the sun these days, but Microsoft isn't one of them. It's an uncomfortably familiar monopoly, no different in principle or practice from all the ones we've seen before. As for the creative genius being trampled by insensitive anti-trust watchdogs -- forget about it. The cutting-edge stuff isn't going on at Microsoft and never has been. Instead of worrying about Microsoft's problems, worry about yours: imagine a world where you could shop for operating systems the way you shop for anything else, and where you wouldn't have to pay an upgrade tax to Bill Gates every few years just to continue using your computer.

Scary, isn't it? Mr. Gates apparently thinks so.

(Back to Karl Fogel's home page.)