Distributions

We wound up working together on an XML appliance product in the summer of 2003 with a startup here in Pittsburgh. We had to put together a custom Linux distribution for that product and discovered that a) it was a lot of work, b) the work was tedious and error-prone, and c) it was expensive as a result.

There are consulting firms that build custom Linux distributions, but they are very expensive owing to the sophisticated labor required. Cobind grew out of our desire to build custom Linux distributions without requiring expensive consultants. That is, a product-oriented solution that makes building custom Linux distributions accessible to a wider range of people.

We were able to launch Cobind, Inc. after we won a fellowship to fund our market research, business planning, product development, etc.

b) Differentiation. There are many Linux package management systems but we believe YUM's architecture and CLI simplicity provided a solid foundation for a GUI with a similar design mantra.

c) Our skills were a good match for the application.

Once the code is integrated into YUM, then it can evolve with the community. We won't make any concerted effort to change the features or interface substantially prior to that code integration.

DW: We believe in the tenets of open source software and the benefits make sense in this case. It would be very difficult to build a GUI on top of YUM if YUM was not open source. So yes, we viewed YUMGUI as a GPL product from the beginning, owing to its extension of YUM.

DW: That's an ambitious but laudable goal and we are a humble bunch. Time will tell.

There is another question embedded in this one which is whether RPM-based distributions would benefit from vendors coalescing around a single package management standard. We believe that everyone would benefit from convergence in Linux package management since that convergence implies network effects benefiting users of the standard. Whether the social forces shaping the future of Linux will allow that to happen remains to be seen.

That said, we believe that YUM, with some additional refinement such as the work being done currently in CVS, is a legitimate contender for that standard package management tool and we remain hopeful.

DW: Yes, fundamentally that is correct. In terms of user interface, the DiY Linux Tools present screens governing brand, licensing, groups,and packages, along with wizards for deploying custom applications such as LAMP.

A big part of the value proposition here is dependency resolution. On the surface, it seems simple to add a package to a distribution,unless you've gone through dependency hell trying to rpm -ivh *.rpm on a single package with deeply nested, unresolved dependencies. The tools demonstrate their utility because you can add packages and the dependency resolver will resolve most dependencies transparently and prompt you when it can't resolve dependencies. In addition the tools have a visual display of the dependency tree which helps people to understand tacit dependencies in the system.

We see three primary markets for the tools:

1) Hardware Vendors who want to produce custom Linux distributions for their hardware (this may range from the vendor doing the configuration pre-sale to the end-use customer using the tool to build the distribution in-line with the machine purchase, similar to Dell's online hardware configurator),

2) Software Vendors who are attracted to the "software in a box" model of selling Linux-based appliances with the software pre-configured,

3) Systems Administrators and consultants who want to use the tools to streamline their Linux deployments on desktops and servers.

Essentially, this system defines abstractions in the UI that make it easier to build and maintain a custom Linux distribution, relative to doing it from the command line. The hard part is finding the places where those abstractions leak and trying to contain those leaks.

There's still a lot of work to be done.

The short term trend for open source businesses is likely to be what you describe. However, in the long term where hardware and software are commodities and developing countries exert significant downward price pressure on labor, it's likely that the margins that companies have enjoyed as benefactors of their own reputation economy will shrink over time. Whether increased volume in open source businesses makes up for the tightening margins remains to be seen. This may be a limiting factor in investment in new open source businesses. It's certainly difficult for a small company to sustain the costs without significant seed capital, pointing toward consolidation invoking economies of scale. That is, the costs may be prohibitive for a small company such as Cobind, but are reasonable in the context of a large hardware company where strategic initiatives (software and hardware being complementary assets) justify the R&D expenditures.