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.