Y2K, C2Net, HKS and Red Hat

| 1 Comment | 0 TrackBacks
| | | |

In November of 1999 I had over a year of work as a professional programmer under my belt working for C2Net Software. It had been a bit of a bumpy ride, by the end of 1999 I had already been hired, laid-off, hired as a consultant and rehired as an employee.

Given the personal struggle and the fact that I worked for an "Internet company", I had a bit of remote detachment about Y2K. But by November 1999, even C2Net was in the mist of Y2K preparations, internally and externally.

Externally plenty of customers had, as part of their own Y2K compliance efforts, started seeking us out long before November to verify that our main product, the Stronghold Web Server, was Y2K safe. The concern being that plenty of elements about managing web traffic require proper handling of date and time information, from the underlying network protocols to creation of unique session identifiers. The good news was that Stronghold, was a packaged and commercially distributed version of the Apache Web Server, which was indeed Y2K compliant, thanks to its many developers.

While most customers went away content with a signed letter of compliance, I remember our Sales and Marketing VP asking me if I wanted to go to NYC on behalf of client and be available if anything went wrong. Basically, since Stronghold was in the clear and any web application the system was running would have been outside of our domain - I was being asked if I wanted an all expense paid trip from San Francisco to New York City to witnesses the ball drop in Time Square for the new millennium1. Naturally, I declined2.

Internally, the biggest worry I had was dealing with our online credit card processing system. First off, the virtual terminal program we had was running on Windows 98, which itself was not Y2K compliant.

However, the bigger problem was the credit card processing software, ICVerify. Today there are plenty of solutions for processing credit card purchases, in real-time, online, from do it yourself solutions such as MainStreet Softworks' Monetra to all-in-one solutions such as Google's Checkout. But in 1999, while a number of virtual terminal solutions, such as ICVerify existed, for processing credit cards "by hand", few solutions existed for processing credit cards automatically, online.

In fact the only reason C2Net's system did real time transaction3 was because ICVerify had been hacked in such as way as to process transactions via a secured network connection. The best part of the situation, like many other Y2K issues, was that the person(s) who had created the "solution" no longer worked for the company, as everyone at the company had been adversely affected by the previous year's corporate turmoil, as I had.

Patching Windows 98 would hardly solve the problem and since no one with the company understood the ICVerify hack completely, it was unknown if patching it would adversely affect our main method for selling Stronghold within the United States.

Given that Stronghold was a commercially distributed version of Apache and Apache at that time was built for Unix (POSIX) based systems, the main requirement, besides real-time processing, was the ability to run along with our custom ecommerce system built using FreeBSD, Stronghold and PHP. That left us with one viable solution, Hell's Kitchen's4 (HKS) CCVS.

By December of 1999 I had already identified CCVS as our would-be solution, to the point that I had actually purchased it on behalf of C2Net and had started developing the replacement credit card processing solution. Doing so had me in contract with a couple of primary individuals at HKS, including the founder, Todd Masco, who must of had his hands full with a few other people, such as myself, rushing to replace their credit card processing systems before the new year. Despite that I don't recall not being able to reach Todd or Doug DeJulio when needed.


Last Remaining Share
Last Remaining Share


That in and of itself endeared me to HKS, but little did I know at the time that wasn't going to be the half of it. While I recall missing the end of the year deadline for getting our new payment system operational by a week (or so), I was hardly in the thick of it. In fact, if anything Todd, Doug and HKS had most certainly had it much worst. For besides the presumed end of the millennium rush to update transaction systems across the nation, in the first week of 2000 the public announcement was made, Red Hat had acquired HKS.

The folks at HKS really had played it cool.

Now here is where things get a bit interesting, the main selling point of Stronghold was that it was a full distribution of the Apache Web Server that included the commercial right to use the encryption technology that allows for secure web transactions, thus allowing one to built solutions such as our custom ecommerce system. As mentioned Stronghold, by way of Apache, was a POSIX based application that ran on systems such as FreeBSD, Sun Solaris and on a the new, up-and-coming operating system Linux which was (and still is) favored by Red Hat. CCVS was a POSIX based credit card processing system.

All of which meant that by the summer of 2000 I received a friendly phone call from Todd, now of course at Red Hat, looking to build contacts at C2Net with regards to possible partnership.

Now it was my turn to play to cool.

Given, in part, the issues at C2Net over the previous year the majority owner of the company was looking to sell and by late spring/early summer the whole of C2Net had been informed that negotiations had been started in regards to Red Hat purchasing C2Net5 and then sworn to secrecy.

So when Todd's call came, I had to politely tell him I would pass on his information to our VP of Sales and Marketing and then of course made a beeline to said office after hanging up with Todd. Sadly, with hindsight and all, I should have realized that if Todd was in the dark about the potential purchase of C2Net by Red Hat, given the obvious fit between the three products, that the acquisition of HKS might have been poorly executed, which in turn was not a good sign for C2Net. But at the time I recall hearing shortly after that Todd did eventually get filled in. And by August of 2000 C2Net and Red Hat issued a joint press releases announcing the agreed upon acquisition.




1 That is of course if, like most Americans, you can't count and/or don't care that our Gregorian calendar had no year 0.

2 Call it Bloomberg's Law or whatever, but in the US one's loathing of all things New York (or Los Angeles) is inversely proportional to one's distance from New York City. Thus, Boston, which is closer, hates NYC greater than Chicago. San Francisco, not so much hating NYC as it does LA. New York and Los Angeles can of course clam no one loathes themselves more than they do, which in doing so means they care little about anyone else, given their immediate proximity to their own location. Having grown up in and around Chicago, I naturally care equally less about New York as I do LA.

3 And for that matter the only reason why we had a machine running Windows 98 in our environment

4 Yes, despite my previous ragging on New York City, I do know that not only is Hell's Kitchen the name of a neighborhood in New York, but if I recall correctly, that the company Hell's Kitchen was in fact named after said neighborhood.

5 A bit fuzzy here on the timeline and details, but I recall hearing about a deal between Caldera and C2Net that never materialized and then Red Hat got cold feet when "the bubble burst" in purchasing Red Hat, until various revenue commitments renewed discussions between C2Net and Red Hat.

No TrackBacks

TrackBack URL: http://pdw.weinstein.org/mt/mt-tb.cgi/181

1 Comment

The Year 2000 problem (also known as the Y2K problem, the millennium bug, the Y2K bug, or simply Y2K) was a problem for both digital (computer-related) and non-digital documentation and data storage situations which resulted from the practice of abbreviating a four-digit year to two digits.

In computer programs, the practice of representing the year with two digits becomes problematic with logical error(s) arising upon "rollover" from x99 to x00. This has caused some date-related processing to operate incorrectly for dates and times on and after January 1, 2000 and on other critical dates which were billed "event horizons". Without corrective action, it was suggested that long-working systems would break down when the "...97, 98, 99, 00..." ascending numbering assumption suddenly became invalid. Companies and organizations worldwide checked, fixed, and upgraded their computer systems.

While no globally significant computer failures occurred when the clocks rolled over into 2000, preparation for the Y2K bug had a significant effect on the computer industry. There were plenty of Y2K problems, and that none of the glitches caused major incidents is seen as vindication of the Y2K preparation. However, some questioned whether the absence of computer failures was the result of the preparation undertaken or whether the significance of the problem had been overstated.

Many banks have responded to the Y2K problem by forcing full 4-digit year entries on cheque forms, which helps to prevent the error from occurring in accounting environments.

Leave a comment

About the Author

Paul is a technologist and all around nice guy for technology oriented organizations and parties. Besides maintaining this blog and website you can follow Paul's particular pontifications on the Life Universe and Everything on Twitter.

   
   


Subscribe:
Add to Google Reader or Homepage
Add to My AOL

Add to netvibes
Subscribe in Bloglines
Add to Technorati Favorites

Powered
CentOS
Apache
MySQL
Perl
Movable Type Pro