a review of Cobind
Not long ago I did
. There's more to Cobind than just a Linux distribution,
though. The company is developing some very interesting tools and
and DiY Linux
. David Watson is listed as Cobind's Founder and CEO. He
graciously took some time out of his schedule for an interview.
Joe Klemmer: Tell us a bit about who Cobind is. There's
a page on your site that lists the team with mini-bio's on it but
how did you guys come together? How was Cobind created?
Bryan [Mills - Founder and
] 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
We were able to launch Cobind, Inc. after we won a fellowship
to fund our market research, business planning, product
JK: There are two major products you are working on,
Cobind DiY Linux Tools and Cobind Software Manager (YUMGUI).
Let's talk first about YUMGUI. What was the impetus for making a
GUI to run on top of YUM?
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
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
c) Our skills were a good match for the application.
JK: You chose Python to develop this tool. Why use
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.
JK: Is YUMGUI in a "production" state yet or do you
still have some plans for expansion? Additional feature?
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
JK: YUMGUI is a good little tool. I know that some
businesses would keep this as a commercial product. Did you have
any thoughts of keeping it as a "closed" tool or were you already
set to GPL it from the beginning?
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.
JK: Do you think that this tool could become a standard
tool for all Linux distributions based on RPM?
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
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.
JK: Now let's talk about your DiY Linux Tools. The gist
of the web page for DiY is that it will help in generating a
custom built Linux distribution. Basically letting anyone build their
own configuration and application base to, in the end, have a
Linux distribution of their own. Is this what DiY is for?
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
3) Systems Administrators and consultants who want to use the
tools to streamline their Linux deployments on desktops and
JK: Can you tell us something about how DiY works under
the hood? Is it also based on Python?
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.
JK: Do you see DiY having an effect on the major Linux
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.
JK: DiY is, initially, going to be available only
through Cobind as a service. Will there ever be an open/free
version of the tools?
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.
JK: It seems that your plan is to have YUMGUI and
Cobind Desktop Linux as your feed and use DiY as your income
generator along with other services. This seems to be the
preferred current model for "Open Source Companies". Is this a
long term trend that you feel is going to be the basis for "Open
Source" businesses for a while?
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
JK: Thank you for taking the time do do this
DW: You're welcome.
to post comments)