My First Exposure to Apache, A Personal Reflection

Technorati just published an article of
mine on this week’s 10^th
Anniversary celebration of the Apache Software Foundation. Alas, given current commitments – consulting gigs and an upcoming
family getaway – I couldn’t bring myself to justify a trip out to
the Bay Area this week to participate. So instead, I present this
personal reflection of my first real exposure to Apache in
celebration of the foundation’s 10-year milestone.

C2Net Software

In
1998, with a freshly minted Computer Science degree in hand, I
received my first real exposure to the Apache community with my first
full-time job offer from C2Net Software in Oakland, CA. I had an
offer sheet, a signing bonus and a opportunity to move to the
technological epicenter that is the San Francisco Bay Area. I had no
idea what I was in for.

By
1998 the Apache Group – forerunner to the Apache Software
Foundation – had already coalesced around a patched up HTTPd Web
Server from the University of Illinois’ National Center for
Supercomputing Applications which had come into its own as the most
popular software for running websites. Companies such as C2Net and
Covalent started building business on packaging the Apache Web Server
with pre-compiled modules such as mod_php and mod_ssl for any
computing platform imaginable, even Windows. But by far the most
popular systems of the day were Sun – We put the dot in dot-com –
Solaris and FreeBSD.

The Internet boom was in full swing.

Being a recent college graduate I had
all of the theory and knowledge and none of the “real-world”
experience. I was hired by C2Net as a Database Engineer. I had recent
exposure to a various Unix-based systems, including one variation
while working for a small business in a Chicago suburb writing Perl
scripts for text processing of information bound for a database and
later computation. I had experience with HTML layout and programming
for the Common Gateway Interface from working part-time at a small
computer bookstore in another suburb. I had even tried to organize an
online resume matching service as a whole-class project in a Software
Engineering course.

However, I was missing two important
pieces; knowledge of a web server software and how to use the server
to bring everything together.

That would soon change. C2Net had been
growing. What had started, in part, in a Berkeley dorm as a Bay Area
ISP that had adopted the open Apache Web Server to combat security
flaws discovered within Netscape’s Web Server had evolved into a
booming business selling a security-minded version of Apache packaged
as the Stronghold Web Server worldwide. Alas, their one-table
incident tracking system that had been hacked together one evening
was in serious need of replacement.

That is where I came in, working with
three other individuals I help developing what is now a days referred
to as a Customer Relationship Management (CRM) System, but at the
time we just called the “All-Singing-All-Dancing Sales and Support
Database” – complete with Michigan J. Frog as mascot – since it
would ingrate sales and support contacts and interactions into a
single database with web-based work queues for pending sales and
support email inquiries.

ASAD: The All-Singing, All-Dancing
Database

Our in-house
e-mail and web-based CRM system started by replicating the basic
functions of the existing incident tracking system, an inbound email
would be parsed and processed based on basic information. If an
incident id in the subject was located the email body was “appended”
to the corresponding incident and the status of the incident was
updated for attention. If the email had no incident number, a new
incident was created, the email was appended and the incident was
assigned to a level-one support tech based on the number of open
incidents then awaiting any one tech to answer.

Staff members
logged into the system using a digital client certificate generated
by an internal, private certificate authority. Stronghold would verify the
certificate against the root certificate of our certificate authority
and then provide the certificate information for the web application.
The application would then use the email address as presented in the
certificate to query the database and generate the user’s work queue.
Since using digital certificates begets encryption all information
transmitted between the server and the client was confined from the
very begging to the very end.

Granted the system
had its flaws too. Today there are any number of robust templating
systems for abstracting the application logic from the display logic.
Many of the program files became filled with dead weight, print
statements repeating over and over the same HTML code for formatting
and display.

But it worked. It
was something more than a collecting of CGI scripts and static HTML
pages on some remote system. It was an application. An application
capable of complex user interactions. An application on a system that
I had direct access to, could review error logs in real-time, could
tweak the performance and before long a system that would be
implement to get important business done.

All of which came
about in great deal because of the Apache Web Server and its growing
community.