Interview with Cobind's David Watson

David Watson: Bryan [Mills - Founder and President] and I have worked together doing software development since the summer of 2001. We have similar views on software design despite our differing ages and skill sets.

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.

DW: a) YUM lacked a GUI and we weren't the only ones looking for one. Since we picked YUM for Cobind Desktop, it was one of the few places on the desktop where you still needed command line skills to install, update, remove, or search for packages.

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.

DW: YUM is written in Python. We believed that if a GUI was going to be successful with YUM, it would have to be integrated into the YUM sources and distributed with YUM. Aside from all the obvious and oft-repeated advantages to developing in Python, the decision was made for us by the YUM team.

DW: No, it's still going to go through some twists and turns before it gets to a stable state. We are working with the YUM team to integrate the code into the YUM source. This is difficult because, as with most projects, the YUM development has not stood still while YUMGUI was being developed. That means there's a bit of a branch and merge issue, where the underlying code has changed substantially, but that's a soluble problem.

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.

DW: The DiY Linux Tools are comprised of a PHP front-end, Python middle tier, MySQL back-end, and Python build farm, with SOAP protocol connecting the tiers. The system defines a data model representing an abstract Linux distribution. The front-end is responsible for presenting the browser interface and doing inserts, updates, and deletes to this data model while invoking events such as build. The middle tier manages build events by queuing builds to the build farm, which scales from 1..n machines. The data model can also be transformed into an XML build descriptor which enables builds to be exported and imported between disparate build systems.

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.

DW: No, all of the evidence suggests that we're running below their radar, with very few exceptions. They've got Point Clark Networks, Progeny, Specifix, and Terra Soft Solutions to keep them occupied. If any of these models are successful, you'll probably see some consolidation in the future though the parameters are hard to predict with confidence.

DW: Perhaps, there are a number of variables impacting that decision and we're not likely to conclude the discussion for some time. Obviously, an open source release of the tools could place downward price pressure on custom Linux development since a variety of the tasks associated with building a distribution are faster and cheaper with the tools, enabling more individuals and organizations to do it themselves while relying on a vendor only for those parts of the system that are not addressed fully by the tools.

DW: With regard to our plan: Yes, we have three broad categories of products: applications, distributions, and tools. We have several applications that we've written which are probably useful beyond our offices, but we just haven't had the time to get them cleaned up for release. Additionally, we have at least one additional distribution that we're likely to introduce to provide a differentiated server offering. Like most other companies in the space, we are using service revenue to support our product development work until the tools are baked.

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.

DW: You're welcome.