Specifix says fragmentation is not a bad thing

The nature of open source is that everyone who runs an application has access to the underlying code. Because they can modify the code, many do. The result can be, and often is, a fragmentation of development efforts. This is generally a difficult thing to manage and maintain, but there are tools offered that can help.

Mainstream companies try to control the fragmentation by writing their license agreements such that you can’t modify their code. You may be able to look at it, but if you change it, at best, you’re on your own for updates and security patches. At worst, you’ve violated your license and may be in legal trouble.

These kind of restrictions generally mean that customers who require kernel modifications are out of luck. Who are these companies? A short list would include hardware makers who need hooks for their equipment added at the kernel level, software companies who need to optimize core functions to speed up their applications, and device makers who rely on highly streamlined embedded Linux.

When these companies do modify their Linux operating systems to fit their business needs, they create several problems for themselves. First, the company that modifies Linux — be it for hardware, software, or devices — essentially becomes an operating system company. It is then responsible for maintaining its code base, patching, upgrading, and so on. Since individual companies violate vendor licenses when they begin modifications, they are on their own for support and must support their customers as well. It’s a huge burden and completely outside of their core businesses, and it involves throwing a lot of money at the problem to make it go away.

De-fanging fragmentation

At the source level, there are tools for managing fragmentation. CVS(Concurrent Versions System) is probably the best known repository and change management tool in the open source community (there are, of course, others). With CVS software, developers can maintain different versions and forks of a code base without devolving into chaos. Up to the present point, this functionality hasn’t really existed at the binary package level. You have to manage at the source level, build and then distribute a monolithic binary package.

So to branch, say, Red Hat Enterprise 3 (RHE), you copy all of the binary packages into a new directory and then beging building, changing, and patching. Then you build a new install and come out with new ISO images. However, the problem comes when the next version of RHE comes out. There are no automated tools to roll your changes into a new version.

Enter Specifix Inc., the brainchild of Eric Troan the first engineer hired by Red Hat, and Kim Knutilla of venerable open source company Cygnus Support, later in charge of compilers and tools at Red Hat after it acquired Cygnus in early 2000. “Cygnus did a lot of early work on customizing Linux and working with customers who needed changes,” says Troan. “They built the tool chain for the Playstation 2, for example.” Troan’s claim to fame, besides having been with Red Hat from the time they were “just a couple of people working out of an apartment,” is that he wrote “about half of RPM.”

Specifix’s Conary is a kind of cross between RPM and CVS that helps companies manage fragmentation at the distribution level rather than at the source file level. Rather than just controlling individual files, Conary can control groups of files across the system with full dependency resolution. “Traditional packaging tools like RPM or D Package are very linear,” says Troan. “They don’t understand the idea of branching. Conary has a very rich branching metaphor for doing distributed branches.”

A company can start with Specifix’s distribution — which has modifications to make customizations easier — branch it, replace the compiler because they need mixed processor support, and make a laundry list of kernel changes for their target architectures. With Conary, a company can adjust only the packages and components they need to change. They don’t have to own Apache if they don’t want to modify Apache. But when Specifix comes out with security fixes for Apache, it’s possible to propagate those changes into the customized Linux distribution. “Conary makes it very easy to move along and track what’s happening in the open source arena while still being out on their own branch,” says Troan.

Conary does all of this in a distributed context. A company maintains a repository that consists of its own code and changes. Conary knows to fetch other packages from Specifix’s central repository or from specified third-party repositories. Each repository operates separately from the others and doesn’t really need to know any others. Conary integrates the various repositories’ packages in your machine.

Care and feeding of a toothless snake

It takes three or four engineers to support and deliver customized OS fixes and updates for a hardware company and its customers, according to Troan. When the next version of the OS comes out, they have two OSes to maintain — more engineers. “With Conary and Specifix as a partner, a company can support multiple operating systems with a single engineer,” says Troan.

Each contract Specifix makes is a little different. “Some companies pay per unit, some customers pay flat fees. The pricing depends on flexibility and what they are trying to do,” says Troan. “Our contracts are in the tens to hundreds of thousand dollars; we’re not talking ten million dollars here.”

Analyst Stacey Quandt of The Robert Frances Group likes the idea of Conary. “Specifix addresses the reality that many Linux users customize their Linux distribution to meet requirements,” says Quandt . According to Quandt, Specifix is an alternative for customers who do not have in-house capabilities — expertise, tools, additional staff — to support a customized version of Linux. However, she clarifies, “Specifix focuses on supporting Linux distributions using the GNU Compiler (GCC). Specifix is not the answer for customers using other compilers such as Intel’s C++ compiler which is optimized for high-performance technical computing.” Quandt figures competition will come from established IT vendors with the ability to support Linux kernels that have been customized for specific workloads.

The long view

“Red Hat doesn’t let people use source code. Novell doesn’t really,” says Troan. “Companies want solutions they can customize. They know it’s cheaper to make Linux fit their business than it is to take an OS they’re not allowed to touch and change and make their business fit that OS.” Troan doesn’t expect Specifix to pass Red Hat in market share. “We’re going after a very different sort of customer,” says Troan. “But I think you’ll see us on a lot of innovative hardware. Conary has exciting technology to do that.”

Conary is open sourced under the IBM Common Public License.