In recent years, I’ve seen an increasing tendency for computers
to be presented, not only to the public but within the industry, as if
they were appliances. I recognize the mindset: the sizes and shapes are
about right, and you plug them into the wall. Just another kind of
television, really. User manuals are seen as intimidating, so the
solution is to eliminate them. What does a consumer need to know
anyway, except where to obtain the product as cheaply as possible?
“Who programs the computers?” she innocently asked Warvel,
the head of Pensions.
“We all do,” he said, turning immediately back to his desk.
“But who,” she persisted, “set up the way it works? The
first programming?”– Orson Scott Card, “Songmaster”
I love good tools. They simultaneously make my life more productive and
more enjoyable. Whether they help manage the medieval technology of
winemaking or the contemporary technology of computer systems, I choose
them carefully and they repay me with long service. I know that many
of you feel the same way. An appreciation for tools and craftsmanship
seems to be deeply part of human nature.
And yet, perhaps not. My girlfriend bought a nail file during a recent
road trip. Well, it looked like a nail file, and it was sold as a
nail file, but it was not, unfortunately, a nail file. Any functional
relationship to the actual filing of nails had somehow been overlooked
during design, manufacture, and sale.
This story would be amusing if it were not so often repeated. Consider
the enormous variation in quality even among artifacts as simple and
ubiquitous as a knife or a wineglass. There are as many miserable
designs to be found today as there are exquisite ones. I confess that I
don’t quite get it. Why, after centuries of use and experimentation,
have we not reached a stable consensus on the design of such basic
tools? There may be a deep appreciation for tools within our species,
but the experience is evidently not equally felt by all.
This thought is all the more disquieting because of its implications for
the relatively new and infinitely more complex world of computing
devices. It suggests that a sensitivity to design is not a given within
our industry. Individuals who have no aptitude for system design may
feel entitled to insist that these extraordinarily complex artifacts are, in fact, trivial or can be made trivial without loss of generality.
This kind of thinking may comfort us with the illusion that
ownership equals mastery, and it may help to sell product, but it seems
to me that it is ultimately a conceit, and an Orwellian one at that.
Instead of encouraging design literacy, it diminishes it. Most
troubling to those of us who see ourselves as system professionals, it
reduces our function from that of “first programming” to that of appliance repair.
We should be suspicious of messages which are dismissive of the
complexity of these systems, as well as of the knowledge necessary to
master them. Such messages play to our weaknesses and encourage a fog
of denial in which we are likely to lose our bearings. I see the dot-com bubble as a tragic example of just this kind of thinking.
Now that we find ourselves in more conservative times, we have an
opportunity to consider how to proceed more responsibly. Let’s not
forget what it means to be human. Ignorance is not bliss. Community is
bliss. In a vibrant community, we each have our specialized pursuits
and talents, but we also cultivate an intelligent regard for the
contributions made by others. Greater knowledge helps us to
appreciate the richness of our lives and to collaborate more
successfully. We come to terms with technical complexity at a more
realistic pace, and with greater respect for design competence.
For those of us who build computer systems as a profession, the open
source philosophy has always been our specific means of collaboration
and empowerment. Like scientists in search of meaning, we turn to it as a laboratory for testing hypotheses and principles of design. Like artisans who love good tools, we recognize in it the means to ensure that computer systems are used to their greatest advantage.
These theoretical and practical insights, and their unbroken relationship to the substance of system design, have
lighted my way through three decades of technological change. I started
out as an application developer, then became a system programmer and
ultimately a system architect. To me, this represents a natural
progression toward the light, toward what we might call first
programming. Computing infrastructure may not at first seem a very
tangible medium in which to express a love of tools and science, but
look more closely. As the ultimate metatool, as the ultimate
laboratory, its appeal is irresistible.
My business as a system architect is to help clients to get the most out
of their computing infrastructure. Open source is part of a rational
strategy for building sustainable infrastructure. The proof of its
viability is all around us, whether in the form of rough consensus and
running code, or in formal standardization efforts and reference
implementations. Organizations that are serious about viability have
to be serious about infrastructure. It should come as no surprise that
they tend to be committed to open source.
Open source puts us in control of the more tangible parts of our
computing environment as well. Open source tools directly reveal their
design and workmanship. This offers an advantage to professionals who
really care about tool quality. We can see the true beauty of the tool
and all its inner workings, not just its surface appearance.
I have reason to believe that open source tools are the only responsible
choice for the highly expert practice of system management. System
management is the active counterpart to system architecture: a practice
which must anticipate changing requirements and accommodate changing
technologies. In this context, professional system administrators are
in a very real sense the first programmers. They must think of the
entire distributed computing environment as an integrated system, and
they must develop techniques to manage systems on this scale. Their
tools must be versatile and highly adaptable to change. If they accept
less than complete mastery over their management tools, they will find
themselves with diminished control over their systems, and entropy will
gradually come to prevail.
Security, of course, is another area where open source makes impeccable
sense, whether we are considering infrastructure, the application layer
or system management. All of my work as a system architect involves
security, all of the time. Security is not something to be considered
intermittently during the system lifecycle. Any infrastructure
component or management tool which is not verifiably secure puts the
entire computing environment at risk. Only open source software is
completely exposed to verification. As security people are fond of
saying, security is not a product but a process. Open source enables
that process.
No manufacturer of machinery is comfortable with only a single source of
components, nor should we be in the software industry, especially given
its characteristic volatility. Open source is an effective safeguard
against devastating risks to supply and interoperability. I never want
to have to advise a client that a project is stalled because it has been
found to depend on an incompatible or insecure component. I never want
to ask a client to choose between delivery and stability. Whether that
component is highly visible or part of the infrastructure, I want to be
in the position to either fix it or to supply an alternative.
I would like to make one closing observation related to the appliance
metaphor. In general, inexpensive computer systems are just as
difficult to integrate and secure as expensive ones, which is to say,
evidently quite difficult. Despite widespread consensus that
configuration consistency is an essential security practice, most sites
report that they do not know how their systems are configured. In other
words, a basic principle of first programming is not being followed at
most sites. The work has somehow not been identified as a priority, and
this, I would argue, is far more a matter of mindset than a real
challenge of technology. These systems are being regarded as
appliances, and the metaphor is not working.
Let’s try to cultivate a different mindset. Open source encourages us
to think programmatically, that is to say, with some appreciation for
the complex way in which systems interact, and without indulging the
popular syllogism that any activity which we don’t understand can
somehow be dismissed as trivial. Tool design is never trivial. While
open source is not a cure for the interrelated problems of complexity
and security, I want to suggest that it helps put us in the right
frame of mind for approaching these problems. It reminds us to respect
the art of first programming.
Dan Razzell is a consultant with
Starfish Systems, advising on the architecture and management of
secure computing infrastructure.
Category:
- Open Source
