There’s no denying that “Linux distributions” have played a central role–arguably the central role–in the evolution of Linux from hobby project to mainstream technology.

However, even as Slackware, Red Hat, and other distributions became “Linux” to millions of users, one inescapable fact remained: that unlike their proprietary OS cousins, which contain technologies developed (or licensed) by a single organization to fit into a single, integrated product, Linux distributions are merely convenient packaging around a loosely knit collection of thousands of independently developed technologies.

Even today, Linux distributions continue to be developed from the top down as monolithic wholes, as opposed to bottom up as collections of piece-parts, a model that would be a much better fit with the nature of every distribution’s (common!) constituent elements. Even newer distributions built by seasoned veterans have tended to follow the top-down model (and, I would argue, to their detriment)–I’m thinking here of Red Hat’s Fedora (which, although called “Fedora Core”, hardly seems a “core” at all, weighing in at 3 CDs) and Bruce Perens’ UserLinux (which appears mired in endless discussions about which technologies should be included and which shouldn’t, with predictable results).

For the commercial Linux-as-product distributors, it is a sensible strategy to portray their distributions as monolithic wholes, as this allows them to position the distributions as platforms unto themselves and, thus, pursue traditional OS business models based on locking users in to a platform (I’ve argued before this will be a losing strategy in the long run, but that’s another topic).

However, for those who view Linux not as a product but as a platform on which to build their own products, the monolithic nature of the typical distribution is a particularly bad fit. The typical Linux-as-product distribution optimizes for breadth–because it is “one-size-fits-all”, it needs to include a huge assortment of features and technologies to satisfy the widest possible audience, only a few of which may be important to any given project (and the few that are important will always vary). Ideally, for Linux-as-platform users, a distribution should optimize for depth, i.e., to excel in those few features and technologies important to the project at hand.

To allow optimization for depth, a new kind of distribution is needed–a componentized distribution from which users may build platforms from the bottom up, including only the features and technologies their products require. Progeny is building such a distribution, which we call (cleverly enough) componentized Linux. Furthermore, we are building it in the open as a community project in the hopes that others will be intrigued with the concept, collaborate with us on the component infrastructure and underlying open-source technologies (Anaconda, APT, etc.) and ultimately build their own components too.

If this sounds a lot like Debian, that’s because it is in many ways: the end result is more of a collection of software than a distribution, and we hope the open development process ends up fostering the same kind of inextricable developer community that has sprung up around Debian. Importantly, the componentized Linux is a layer above an existing distribution–or, more properly, above an existing collection of packages. Our components are currently based on Debian sarge, and we are planning to support Fedora-based components as well in time. Our LSB 1.3-certified core runtime is available today. More components and a component-aware, Anaconda-based installation mechanism will be added in the coming weeks.