A Question Of StyleA Question Of Style

Open-source software development is, for many of the people involved, a matter of style. Whether or not that's a gross generalization, it reflects a popular image of the open-source community: freewheeling, individualistic, and either irrepressibly creative or hopelessly chaotic, depending on one's point of view.

Naturally, Microsoft--the world's largest and most successful commercial software company--represents the opposite stereotype: centralized, businesslike, and either solidly reliable or hopelessly bureaucratic, again depending on one's point of view.

In reality, people on both sides of the open-source fence can, and do, learn valuable lessons from the competition. And as information's John Foley points out this week, the development philosophies behind the Windows platform and the Linux kernel both stand to benefit from these exchanges.

Today, the organizations driving Linux kernel development are launching an interesting experiment. Instead of working on parallel developers' and production kernels--the standard, time-honored Linux development model--they're experimenting with a single version from which stable production kernels could emerge several times a year. That's a far cry from the process that produced the Linux 2.6 kernel, which took nearly three years to mature after the version 2.4 release.

One of the goals here is to get a leg up on Microsoft by delivering new features more quickly and by adapting more effectively to enterprise customers' needs. While Microsoft sticks to a philosophy that lays out product roadmaps several years at a time and generally avoids dramatic change, the Linux community is testing an approach that favors short-term adaptability and innovation over long-term predictability.

This is a bold experiment, given the fact that Linux is just beginning to establish itself as a serious alternative for high-end enterprise applications--a change that's due, in part, to the Linux 2.6 kernel and to the process that produced it.

In spite of Microsoft's often-missed deadlines and technological inertia, however, the company's development methodology gives companies something they often value more than innovation: the ability to see into the future and to plan their IT investments accordingly.

As Foley observes, Microsoft is slowly moving towards a more flexible development process that still gives customers a clear technology roadmap. The Linux community's experiment with a very different approach reflects many of the traits that have made the open-source model so successful. But it would be a mistake to press ahead with change simply for the sake of change--an approach that may not win many supporters in the enterprise IT departments where the Linux community is betting its future.

That's apparently a more controversial point than I expected. According to Foley's own blog entry a few days after posting his column, his suggestion that Linux could benefit from a long-range development roadmap struck some Linux partisans as pandering to Microsoft's development model.

Yet the need for a kernel development roadmap, and for a level of coordination that makes a roadmap possible, is precisely the sort of change the Linux community should be considering much more seriously. Enterprise customers have good reasons to demand this sort of planning tool; it strikes me as odd that anyone familiar with how and why companies plan their technolgy needs would find the idea of a roadmap controversial.

I don't think this type of reaction is truly representative of the Linux development community. If it is, however, I have to wonder whether Linux is truly ready to compete against Microsoft in the enterprise market.