Making the Decision

The first, and probably toughest, part of this migration was to actually make the jump. This site, and every bit on it, is something I’ve carefully crafted over the years. Up to recently, I could proudly say that every piece of code on the site was something I had written myself. It was a point of pride and, while blog software was still new, it was also a way to experiment and go deep into the code. Over the years, though, software platforms have gotten more and more complex and my own code failed to keep up.

The second part of the decision in making the jump was also due to my focus on spending more time writing. However, this was balanced by my need to tinker with the code. As time went on, it became more and more difficult to figure out where I wanted to experiment.

Last but not least in that decision was the fact that everything I was building was my own but not something I could really share with anyone. Time and time again, people asked me how I implemented a particular feature on my blog and I had no way to deal with this than to pass the whole code, ugly commenting and all, to them.

Last month, the main drive on TNL.net crashed, something that appeared like a disaster at the time but was really a blessing in disguise. Having to rebuild the box, I decided that it was time for a massive upgrade. First, I would upgrade the operating system (TNL.net had been languishing on an old version of Redhat Linux 7.3 for so many years due to some bad system design decisions I made when I moved to Linux a few years ago). Having done so, I also decided to upgrade the web server (to Apache 2.0), the database (to MYSQL 5) and the programming language (to PHP 5). It was a major upgrade and, as is the case with every major upgrade, things started to break. I spent a considerable amount of time bringing things back up and reintroducing tweaks that had built up over several years. It was then that I realized that maybe a different approach was needed.

Who are the contenders?

Having decided that I would upgrade the blog to someone else’s software, I had to establish what factors I would consider when building the new site. From there, I built a quick list:

• The software I would take had to be something I could tweak: While I’m leaving my existing code base behind, I still want to have some level of control over what goes on under the covers.
• The software I would use had to be open source. My reasoning for this is that open source not only means free but it also means that I am not worried about control issues further down the road. So any changes that I make and then redistribute doesn’t fall under some kind of corporate legal entity and therefore (fingers crossed) I won’t have to worry about legal issues relating to my amendments.
• The software would have to be extensible through some type of plug-ins or module infrastructure.
• The software would have to be written in PHP and use MYSQL because those are technologies I’m familiar with and I didn’t feel like learning something new.
• The software would have to match the features I had running in my existing blog.

Having those requirements made the choice considerably easier, as it left only two major contenders: Drupal and WordPress. In the end, I decided on WordPress for purely visual reason: the admin interface just struck me as much more polished so I went with it. Drupal had a geekier feel to it but WordPress felt like a more finished product (and here, I may show some bias for interface).

Starting the migration

The first step in migrating things to move over was to figure out what I needed to migrate. One of things I wanted to ensure was that any upgrade would have little or no impact on the overall feel of the site. I’ve spent a considerable amount of time tweaking TNL.net so it did not necessarily feel like a blog and so that the user experience was always as optimized as possible, allowing people to get to any content within only a few clicks.

First Challenge: Look & Feel

This presented some challenges: the first challenges was in keeping the interface consistent. Most blog packages come with a set of skins or themes that are used by beginning users. I, however, set out on a path to change the whole look and feel to mirror exactly (pixel perfect) the previous look of the site. This sent me down the path of theme development for WordPress and I spent many hours learning about the internals of the system in order to make it do what I wanted it to.

The other look and feel challenge was in the URL structure of the site. For years, the URL structure on TNL.net has not changed however, I’ve always been bugged by some of the limitations I had created for myself. For example, entries could not have the same title because I had created a system that prevented me from being able to do so. It seemed clever at the time but turned out to be a major design flaw. As a result, the URLs for every entry sat at roughly the root of the site. I wanted to make sure that any Google juice or other types of linkage would not break so I had to write my own routine to redirect pages correctly. This ensured that the URL structure of old could still remain.

Second Challenge: Data structure

In the process of writing my own blog, I defined my own data structure. I wanted to ensure that it would be followed in WP but it took some tweaking to get everything to map correctly. However, thanks to the RSS importing feature, I was able to import most of the old entries without problems. This, once again, was to ensure that continuity would remain unbroken and that the site would still function as it always did.

However, a second challenge was in importing comments. I’m still trying to figure that one out as I’m working on importing all the comments back into the new system. They’re temporarily offline but they will come back.

Third Challenge: RSS feeds

A substantial amount of TNL.net reader never visit the site: they get it via RSS. This presented a new challenge as I wanted to ensure that they would remain mostly undisturbed through this transition. In the process, though, I decided to move to a new model that would ensure they never have to worry about such URL changes. I redirected all the feeds to new URLs (http://feeds.tristanlouis.com/TNLnet for the excerpts feed and http://feeds.tristanlouis.com/TNLFull for the full entry feed) which are now powered by FeedBurner, allowing me to get a better understanding of who my readers are while helping migrate them from one platform to another. In a sense, FeedBurner is now serving as a migration tool while at the same time providing me with a new URL schema that I could take anywhere I want.

Conclusion: A pretty seamless transition

All and all, while it was some work to get most everything working, the transition has been pretty good so far. I’ve gained a fair number of new features and am still exploring how the system works. It seems to be much more feature rich than any code base I developed so that’s another great relief. On the downside, I feel a little sad to let go of a large chunk of code powering the site (the TNL.net blog was powered by a 90k PHP file which will soon be cleaned up). I’m still considering adapting the old code to deal with the front end of TNL.net but, all and all, it looks like WordPress will be my blogging tool of choice… until I decide to switch again.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title On the WordPress move. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

Certain software companies have been suffering from the advance of modularity in software design. The main one, to date, has been Microsoft with its Windows software platform. In the mid-nineties, Microsoft decided to integrate a number of Internet components tightly with its operating systems offering. The two most critical ones of those components have been a web server (IIS) and a web browser (Internet Explorer). Leaving aside discussions relating to the antitrust issues this kind of integration has raised, the integration of those tools with the operating system have left openings for alternative approaches that were more modular.

On the server end, IIS has been the subject of many attacks by hackers. Because it is hooked deeply into the operating system, an attack against the web server can have an impact that goes much further that the web front-end. In most cases, the attacks succeeded not only in taking machines down but also turning them into zombie armies that could then turn around and attack other servers. In 2001, the Code Red virus successfully infected hundreds of thousands of machines in less than 24 hours. Subsequent viruses built on this approach and have been responsible for some of the largest attacks against Internet systems to date. The news that the system had built in back-doors only furthered the issue, presenting an opening for other software developers.

The open source movement exploited this by presenting an alternative with Linux and Apache. The Linux operating system, which is modular by design, can be fined tuned and services can be included or not depending on how one wants to shape their system. A web server like Apache can be included in the OS but doesn’t have to be. Because of this modular approach, Apache (which runs on a number of different operating systems) has gained the high ground in terms of marketshare. The Apache project focused on delivering modular components, which represent a tool-set for most web-based application.

The same is true on the desktop end. While Microsoft decided to tightly integrate its web browser with the operating system, making it easier to create lock-in for that platform, the approach backfired when hackers developed viruses and trojans that exploited flaws in the browser software to get to the operating system. It was only a matter of time before users started getting annoyed by the number of attacks and looking at alternative. They found one in the Mozilla foundation, a group of open source developers who created a modular Internet product suite. Because the Mozilla products were built in a modular fashion, the first attack was responded to in less than a week. This quick turnaround in fixing the bug was due to the way the code is implemented: because it is modular, it was much easier to fix and because it does not communicate deeply with the operating system, it represents less of a risk than Internet Explorer and has been recommended by security experts like CERT.

While the browser and web server represent applications that are bundled with an operating system, some people are looking to go much further by modularizing the operating system itself. When broken down to its smaller components, an operating system can almost become device-independent, providing interactions between different components to create a whole that is greater than the sum of its part. Future operating systems will be able to evolve across multiple devices, whether they are computers, mobile phones, televisions, or other devices we have not imagined yet.

This kind of distributed system already exists but in a limited fashion. Some organizations have used Linux to create supercomputers by connecting multiple small machines. The power given to those allows to greatly reduce the overall cost of building very large machines. Similarly, one of the largest web-based application, Google, uses tens of thousands of machines which interact with each other as a single system.

The lesson in this approach is that a modular approach always wins over an integrated one because it reduces costs and increases scalability, thus ensuring greater flexibility. While one can never predict changing markets and future developments, a modular approach is always more flexible and easier to evolve over time.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Modular by Design — Software. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

• Physical security for electronic systems
• Rigorous testing of electronic machines
• Properly trained poll workers, and rapid-response teams on Election Day
• Public records at the precinct level
• The option to vote non-electronically
• Independent security experts
• Transparency in electronic voting

Looking at this list, it seems that an e-voting system would benefit from being open-sourced.

Democracy and Open-source

My first reason for mentioning open-source as the savior of e-voting is that the open source community is inherently democratic in its nature. If you have something to contribute, you just go ahead and do it. If it’s good enough to withstand the scrutiny of other developers, it gets used. If it isn’t, it gets abandoned. This system of peer-review has already helped in turning some projects into the basic foundation of the everyday Internet: BIND basically covers how Internet addresses are translated from numbers to more friendly domain names; Apache powers the majority of the web servers in the world; Sendmail still sits at the core of most email implementation. Quietly, each of those tools gets improved by open-source communities, which can be seen as the best example of meritocracy in existence: you are what you contribute in the open source space.

Because the open-source community is a global one, tools can take into accounts variations at local levels, which is also something that benefits a more democratic process.

Democracy, Open Source, and weblogs

Weblogs have, other the last few years, added a missing component to the open source community: non-techie user feedback. When a blogger complains about a particular open-source tool, he’s providing feedback as to what works or doesn’t. In some cases, it can get contentious, as techies sometimes dismiss the user as clueless; but in other cases, it can be a good way to provide feedback.

E-voting as the most important open-source project

At the core of the open source argument is the concept of openness. At the core of the democratic argument is the concept of… openness. A strong democratic society stays open. However, power lobbies attempt to close things down for their own benefit. We’ve seen it happen around copyrights in the United States and are now seeing it happen in a number of other areas. In a strong democracy, watchdogs keep those attempts to be overly abusive. One way to ensure that they’re not is to provide some of the basic tenets of democracy. As a result, I’d venture to say that creating an e-voting package that is freely distributable is one of the most important projects the open source movement could undertake.

E-voting: A lot of work

Creating a good, secure, and open e-voting system is a lot of work. The work spreads across two key areas: hardware specifications and software development.

On the hardware end, a base implementation needs to provide a system that is inexpensive (so it can also be used in poorer countries), secure (so it cannot be tampered with), stable and reliable (so it does not add complexity to managing the electoral process), easy to use (so non-techies can put them in place and maintain them) and auditable (so its value can be proven).

On the software end, the software must be reliable and stable (so it doesn’t disturb an election), secure (to solve existing problems), auditable (so it can leave a trace of anything done to the system, either on the administrative end (setup and maintenance) or on the usage end), anonymous (so one can’t track who voted for whom), easy-to-use (so that even non-computer users can use it), scalable (so that it can be used at the local as well as national (or supra-national, in the case of Europe) level).

This is work that will need to bring experts from a number of areas in the open-source community, from people well versed on security to people well versed on design. However, because of diversity in the open-source community, the experts already exist. The question that remains is how to bring them together.

A long term project

In 2000, I called for more computerization of the voting system. Four years later, we seem to be facing similar predicaments. The private sector has stepped up to the plate but seems to have failed on a number of fronts, one of which is transparency. Considering that vacuum, it looks like it’s time for the open source community to step in. Results won’t be clear for many years to come, which makes it more difficult to manage as a long term project. However, projects like Linux did not just pop-up all built. To date, they have been the result of continuous improvement to a strong core.

The real test would be to see those machines deployed on a short term basis to do things like non-government related elections (maybe initially to vote on things like who gets to sit on the board of a foundation that would run this effort moving forward), and as time goes on, test them in school elections, then local government elections, and so on… As a result, it will be a project that will probably not alter the course of a democracy for at least another decade.

Can the open-source community work on such an effort for as long a time? I believe it can.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title E-voting and the Open Source community. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

The Genesis

Since 1995, TNL.net was running on Microsoft Windows. Initially, the site was running on Windows NT, using Microsoft IIS to serve pages on the web. Prior to that, TNL.net had been running on a shared Linux box but none of the administration of that server was in my control. When it moved to its own environment, I looked at a number of options that would allow me to spend time developing the site, not necessarily administering the box. In late 2000, the site was upgraded to Windows 2000 and continued to run on this until recently. So why did I decided to change things?

Unhappy with Microsoft

The world in 1995 was very different from today’s world. In those days, administration of unix system required a set of specialized skills and administrators had to design their own programs to automate a lot of work. Over the years, more products started coming out of the open source community that would simplify the way one manages a Linux box.

Step 1: Moving Up, Moving Out

In parallel, Microsoft started going further and further upstream in search of new revenues for windows. Having successfully conquered the desktop, they first set their sight on small business. With the introduction of Windows 2000, they started upping the price of internet servers, requiring a separate set of licenses for the internet services as an add-on to the operating system costs.

As TNL.net grew more and more popular, it became quickly apparent that the small MS-Access database that was powering the server needed to be upgraded.

Step 2: Patch, Patch, Patch

After buying a license to SQL server, I learned that I had to start worrying about another set of patches on a weekly basis. As new security patches were released weekly for windows 2000, IIS, SQL server, I found myself spending more time doing basic administration of the box and less and less time doing development on it. With a limited time resource, this became a first point of concern and pushed me an area where I started questionning whether I wanted to stick with the platform for the long term.

Step 3: Price Hike

After careful study of the windows roadmap, it became apparent that Microsoft was no longer interested in small and medium size sites and was getting more and more targetted towards the enterprise. The introduction of .net was clearly aimed at the enterprise market. The subsequent announcement of changes to their licensing structure showed that they would drastically increase prices and force you into an upgrade cycle, whether you liked it or not. Microsoft was essentially telling me that if I wanted to play long term, I would not only be forced to pay more but also be forced into buying software on a subscription basis, whether I liked it or not. This would not do. I was already an eager Microsoft user and, having paid for all my licenses, had already laid out a substantial amount of cash into staying with Microsoft.

Step 4: Locked up

To look at a change in platform because of a new pricing model was an important step but was it really what I wanted? I decided to approach a few people I knew in the community and within Microsoft to see what the general view was. Maybe I was over-reacting.

Service Pack 3 showed me that I was not. With it, Microsoft essentially was telling me “open your box to us and we will take care of everything”. Everything, that is, that Microsoft deemed OK. Which essentially meant that I would let Microsoft decide what could and couldn’t be on my box. For purely historical purpose (as I expect this story, like all the others on TNL.net, to stay on the web for many years to come, you have to realize that all this is happening against the backdrop of Microsoft being investigated for antitrust violation)

Step 5: Looking to the other side

One of the things that allowed the Internet to grow as quickly as it did over the past decades is the fact that most people are willing to share. However, in the windows world, the logic is that what you create is for your own and you charge for it. This left me in the odd position of being one of the very few open-source windows developers in the world. If I had a cool piece of ASP written, you just had to ask and I would send you the code.

Meanwhile, the open source community was producing products that were growing more stable by the day and at a fraction of the costs offered by Microsoft. Most of the products were running on Linux, using Apache as their web server. By 2001–2002, they had grown mature enough to being considered enterprise grade.

Checking out the alternative

Once I decided that I would move to an open source platform, I had to investigate the alternative. The question became what operating system, what web server, whether to use another application server, what language to use for developing my back-end, whether to use a database (and if so, which one).

Choosing the Operating System

Should I go with Linux or BSD or something else? If I went with Linux, which distribution should I follow. In the end, I decided to settle on Linux because of the wide level of support if had not only on the open source market but also in the commercial one. With backers like IBM, Oracle, and even (begrudgingly) Sun Microsystems, I feel that Linux is here to stay and will continue to grow not only as a hobbyist OS but also, increasingly, as one of the foundation tools for web businesses of the future.

However, looking at the different Linux distribution was a much more complicated matter. I wanted something that would require little day to day administration and could be easily and quickly patched. At the same time, I had to ensure that the operating system would run on the new TNL.net box, a dual 1.3Ghz Pentium configuration with a SCSI RAID array. Unfortunately, I learned one of the tough lessons of the Linux world very quickly: Hardware drivers in the Linux world do not always get upgraded at the same speed as the rest of the Operating System does. In the case of my box, I discovered that, while there is a new kernel patch coming out every few weeks, it is impossible to keep a machine up to the latest kernel if you have a proprietary set of RAID drivers. This is a shame on the part of the driver makers who could either produce source code for the drivers and let the community update them or keep up with the demand. Attempting to do a kernel upgrade proved to be a fruitless effort as my options were either upgrade and lose the RAID array configuration or wait until the vendor releases new RAID drivers.

In the end, I decided to pick up RedHat Linux 7.3 because my RAID vendor supported it and because it offered superior auto-updating features through the RedHat Network. Some members of the open source community will groan as RedHat is often seen as the Microsoft of the Linux World but I feel that it is currently the easiest point of entry for an ex-Microsoft user like myself.

Only one choice on webserver: Apache

Having made the decision as to what Operating System to use, I turned my attention to the web server. This decision was a much easier one to take as the web server from the Apache Foundation as become the de-facto standard for anyone who is serious about delivering web content on an open source platform. I did not go very far in my research on alternative web servers. The only decision point on the web server end was whether to use Apache 1.3 or Apache 2.0. Influencing this decision was the module architecture that Apache offers. Unfortunately, at the current time, Apache 2.0 is too new to have as extensive a set of modules as Apache 1.3. As a result, I decided to act conservatively and use the 1.3 version.

Backend: What to use?

Coming from the Microsoft world, I have had extensive experience with ASP and could have kept using it thanks to a helpful module developed to run the Microsoft technology on Linux. However, I had already made the decision that I would rewrite substantial parts of my code so I decided to completely abandon ASP as part of the migration.

My choices were therefore perl, PHP, Java, and Python. Each of the languages was equally good for what I wanted to do.

Perl, which I have used for years (the original TNL.net was running in Perl as Microsoft had not put out any offering at the time) would have been my first choice if I had wanted to do a quick and dirty migration. However, Perl had gotten old and was not designed per say as a web scripting language.

Python looked very interesting but the syntax seemed a little too arcane for my taste.

Java looked interesting but, having made the decision to leave the Microsoft platform because I did not want to become beholden to a single company, would I end up making the same mistake by going the Java route and become increasingly beholden to Sun Microsystems. That particular fear kept me from going the Java route.

PHP seemed to have managed the proper balance between extensability and ease of use. It seemed like a new language developed specifically for web use and I had not played with it. The big question on my mind, though, was whether it could support large amounts of traffic.

At the time of the migration, TNL.net was already received upwards of 3 million page views a month and growing slowly towards 4 million. As if someone had read my mind, Michael Radwin made a presentation highlighting how Yahoo had come to the decision of using PHP. Reading their analysis of the different languages, I felt that someone else had gone through the same thought process I did. While they did not include Python (why, I do not know). However, their conclusions were that PHP was solid enough to run large portions of the Yahoo site. If that was the case, there was now no doubt in my mind as to which scripting language I would use.

Choosing a Database Package

Once I chose PHP as my development language of choice, the next step was in assessing which database I should use. After carefuly consideration, I decided to use the mySQL package largely because of its tight integration with PHP. Furthermore, investigation showed that this is a relatively standard configuration known as LAMP and is being used by a number of people all over the net. More powerful options are offered by other open source database packages like PostGresSQL but I came to realize that for most things, MySQL is the best package for me because many of the features offered by other package are on the list of things I do not plan to use at any time in the foreseeable future (12 months).

Conclusion

Having moved to an open source package was much easier than I had initally expected. With a complete rewrite of the back-end TNL.net code, I was able to clean things up and make sure that the site was optimized to support the traffic it’s been getting to date and still have some room to breathe in terms of supporting more traffic. In the process, I made a decision to get rid of some old things like the DMOZ implementation I had and introduce new ones like the TNL.net weblog, which now provides some content on a more regular basis (at least 5 times a week). I have already seen some dividend in my joining the open source community, as some of the code implemented by other people served as a blueprint for the new TNL.net. All and all, count me on the list of people who have made the switch from windows to Linux. I don’t think I will look back any time soon.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title TNL.net moves off Windows. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

A Rapid Epidemic

Now that I’ve got your attention, let’s take a quick look at how Code Red spread. First of all, there was a simple buffer overflow problem in Microsoft Index Server, for which the company produced a patch. A month later, Code Red starting showing up. However, its rate of growth was relatively slow at the beginning. The true epidemic did not start until July 19th, when Code Red exploded onto the scene, increasing the number of infected servers from just around 300 at 00:15am to 2994 by 7:30am, over 30,000 by 14:40pm and over 300,000 in the 6 hours after that. In other words, in less than a day, Code Red went from a relatively small annoyance to a full blown attack on the net infrastructure. Had no one rung the bell on it, it would have taken only a couple of days for it to infest every single version of Microsoft IIS (or about a quarter of all web sites on the net).

Who’s responsible?

While the hunt is on for the person who devised this virus, the list of people who have some level of responsibility in the spread of this virus is a very scary one: Microsoft, of course, for first putting out a faulty product, a web server with a big security hole. However, credit goes to Microsoft for putting out a patch before they even knew of the worms’ existence.

Another group which deserves some blame is IIS system administrator of infected systems. Let’s face it, we all know that Microsoft software is riddled with holes. We also know that Microsoft puts out patches on a regular basis. We all know that those patches solve most of the problems before they occur. Well, the people who were infected by Code Red did not follow the basic rule of patching systems early and often.

Many Unix administrators are laughing right now at IIS users: they shouldn’t!

The security on some Linux systems is so dismal that a virus similar to code red but aimed at Apache servers could have done much more damage much more quickly.

What have we learned?

The first thing that we have learned out of the code red offensive is that we can’t rely on people to update their systems properly. When system administrators fail at that task, they contribute to a lower level of security for the net as a whole. But SAs are human and to err is human. The truly scary thing is that Code Red is only the first of a series of viruses that will gain preeminence on the net.

The truly scary thing is when an application used by general consumers gets attacked by a similar worm.

Earlier this year, I covered a set of security problems in AOL’s Instant Messenger. One of the ways hackers are taking over AIM is using buffer overflow, throwing large strings of apparently nonsensical characters to the client in order to take it over. Unfortunately, Code Red acted the same way with IIS servers. What will happen when someone uses the Code Red approach to create an attack on AIM? The thought sends chills down my spine as I can see hundreds of millions of computers acting as zombies in a possible net-wide denial of service attack.

Mutations

During the August 1st attack, webmasters noticed not one but two (and possibly three) different types of code red attacks. The first one was the same as the July 20th worm but the second was much more nefarious, a worm that did not announce itself (it did not deface web sites) but instead added a backdoor allowing hackers access to the compromised servers. When work done on one virus reappears in another, we call it a mutation. What is truly worrisome is that Code Red was not a very sophisticated virus. Others, like Hybris can update themselves.

What happens when Code Red is merged with one of those other viruses? This is yet another scary question that I send out for discussion.

Infrastructure

For the past year, I’ve been paying more attention to the security space. I wasn’t sure of why but I felt that this was an area I needed to pay attention to. More and more of our technological infrastructures are moving to the Internet. These days, telephone companies, cable companies and many others are tying into the grid. However, it seems to me that little attention is being given to security. As we move into the era of web services, there needs to be an important dialogue in our industry as to how we increase the security and reliability of the Internet.

Furthermore, as new operating systems come out, they should be thoroughly proofed for security holes. Apple recently released OSX and already, a number of holes are being noticed. Microsoft is still set on releasing Windows XP within the next few months but few in the security community have had a chance to test out its security. With all that said and done, I would also like to encourage all of you to question whether any of your connections are secure. For example, if you are running a DSL or cable line at home, have you firewalled your environment? These days, it’s little things like that that make a lot of difference.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Seeing Red. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

I regret to announce the end of my efforts to mediate the Microsoft antitrust case

said Judge Posner in a statement released on Saturday, April 1st.

But it wasn’t.

After 4 months of discussions, any chance for a settlement between Microsoft and the US government seems to have ended fruitlessly. Many magazines, newspapers and web sites have been pointing out the fact that Judge Posner did not thank the states for their work in his brief statement. As a result, many believe that the states’ demands were largely responsible for the breakdown of the talks.

But the question remains as to what was the content of those talks. While most of the 20 drafts that were put together by the DOJ and Microsoft were kept a secret, word has leaked out regarding the content of some of those drafts. It includes:

• Uniform pricing structures that would disable Microsoft from offering preferential rebates and creating bundles for some partners.
• A provision forbidding Microsoft from striking exclusive contracts with other companies (for example, as it did with AOL, giving it an icon in Windows in exchange for packaging IE)
• Full disclosure of all the API to all Microsoft software, giving away what has long been believed to be a Microsoft advantage as it was supposedly allowing Microsoft internal programmers to develop software that better integrated with the Windows OS.
• Box manufacturers would be given source code to Windows and allowed to modify it at their will. They would be able to add and remove new features to it, such as, for example, changing the web browser. Microsoft would not be responsible for supporting those modified versions of windows.

Meanwhile, the 19 states involved in the negotiations would not go for anything less that a full break-up of Microsoft into several Baby Bills.

However, when you look at it closely, the proposal of the 19 states may be a bit shortsighted.

By creating a set of Baby Bills, we might end up with not one but several monopolies: One in the OS space (Windows has over 90% penetration in the consumer market), one in the application space (Office has more than 90% market share in the office suite market on both the PC and the Mac), and potentially in the Internet space (Internet Explorer has now supplanted Netscape Navigator as the browser with the largest market share).

However, while this case has become the computer equivalent of afternoon soap operas, with people tracking its every move, whatever happens this week when Judge Jackson presents a ruling that will most probably be unfavorable to Microsoft, may have little influence on the computer industry.

First of all, Microsoft will most probably appeal the ruling, going all the way to the supreme court and thus delaying its final impact for at least another year.

For starters, a lot of the battle is around Microsoft Windows and its larger implications in terms of helping Microsoft control the Internet. However, the landscape has dramatically changed since the DOJ and 20 states filed their case against Microsoft. The case was originally kicked off by Netscape as a salvo against Microsoft in the browser battle. Since then, Netscape has become a unit of the new behemoth in the Internet industry: America Online. AOL, which recently announced it would acquire Time-Warner, was playing both side of the fence. On the one hand, they are Netscape’s owners, and on the other, they are bundling IE as part of their client (of course, this allows them to also have an icon in Microsoft Windows, which has been in large part responsible for their success in customer growth).

At the time, Microsoft did have an inferior browser and was loosing in the marketplace. However, with the release of IE 4.0, and subsequent release of their 5.0 client, they started to gain market shares. Netscape was not happy about that. On the one hand, Microsoft was going faster than they were in terms of releasing new products. And, on the other hand, Microsoft was working on developing a version that would run better on four platforms: Windows, Macintosh, Solaris and HPUX. Meanwhile, Netscape was trying to support their browser on no less than 18 different platforms.

The interesting thing was that Netscape was complaining that Microsoft was going to compete with them. Yet, they were making it clear that they were out to:

replace Windows

and when they lost went to the DOJ to complain about Microsoft making their browser available for free even though they had adopted the same tactic long before Microsoft did.

Netscape’s failure was in the marketplace but since resentment of Microsoft’s success has always been a good thing to bet on, it played the legal card and got the proceeding started.

Meanwhile, Microsoft pushed more and more products out but failed to capture significant market shares in some critical Internet areas.

First, it attacked the online service business. AOL became the top online service, beating out Microsoft’s own MSN, even though MSN was bundled with Windows (this interesting little fact seems to show that bundling software with Windows is no guarantee that it will win out in the end.)

Realizing that it was loosing on that end, Microsoft decided to recast MSN as a portal but that decision was made too late and Yahoo! became the top search engine, followed by AOL’s own site.

On the server end, Microsoft is still trailing the free Apache server for the top position by a very large margin (Apache has a 60% market share, while Microsoft’s IIS has a 20% one). It’s efforts to cast its back-office suite of tools as the Internet suite of choice seems to have gone about as badly, with Microsoft trailing Oracle in the database space. Furthermore, some of Microsoft’s efforts to capitalize on their windows platform (remember ActiveX anyone?) have been received with less than enthusiasm by the development community… and let’s not forget Linux. While Microsoft was trying to make a big push against Solaris on the server end, the Linux crowd started going after the mid-size server market. As a result, Microsoft has not participated in the growth that other server-end operating systems have seen in the past few years. Linux has taken most of that growth away from Microsoft, representing a major threat to Windows NT. Linux has now become such a threat to Microsoft that the company is now breaking its own rule of never mentioning some other company’s software in presentations.

In new markets, Microsoft has also seen some very strong competition. While it has been moderately successful in the convergence space with WebTV (a company it bought for $420 million), the battle is just starting and AOL will soon be able to bring the power of its 22 million strong user base to the party, giving Microsoft’s some new headaches (WebTV has about 1 million users).

On the wireless end, Microsoft’s attempt to push Windows-CE against the PalmOS has been rebuffed and Palm computing has been very smart in licensing its operating system to cell phone vendors and other partners, creating a new platform Microsoft has to battle.

Last but not least, Microsoft is now trying to enter the gaming console market (with their X-box, promised for a Christmas 2001 release) and is thus entering another market in which it has little or no market shares.

When you look at this, you may say, well, why would anyone care about Microsoft’s dominance. It seems to be waning, right?

Well, yes and no. While the market is currently showing a company that’s fighting a war on multiple fronts, it’s also a company that has successfully managed to buy itself a seat at the telecom table (Microsoft now has investments in AT&T, Comcast, Nextel, and Qwest), as well as some other infrastructure plays (Akamai, Concetric Networks, Tut Systems).

What’s happened really, over the last few years, is that Microsoft stopped being a pure software company. Sure, it still sells software but its main business over the past few years has been as an investment firm. When you look at it this way, its dominance may somewhat make sense, much like Kleiner Perkins’ does.

As a result, I’m afraid a breakup could represent a major problem for our industry. For starters, look at the suggestion that’s been the most often floated: one company doing windows, another doing applications, and another doing Internet stuff. If you go with that breakup, you still have a dominant player in the OS market, a dominant player in the applications market (remember, this group would get MS Office) and a weak Internet company.

Most of Microsoft’s problems have stemmed from the fact that it has grown too big for its own good. For starters, it is now in so many markets that it is hard to figure out whether it really does wield as much power as it used to. Second, it is such a big organization that I seriously doubt programmers talk to each others as much as they should. However, if you were to break it up as more than three companies, you could get somewhere.

Let’s say we were to follow the logic of Microsoft as a VC firm. If we do so, it’s market cap is really not so huge, considering the number of companies it holds. It is, after all, a VC with over 200 companies in its portfolio.

Either way, the battle will go on and sometimes this week, a ruling will be issued but in the long run, I seriously doubt that anything that happens this week will have any lasting effect on the computer industry. Microsoft will win out or loose out in the marketplace, regardless of the outcome of this trial.

We’re living in too dynamic a marketplace for it all to make sense. In the end, however, we will all regret that case ever happening because it will set a precedent as to whether the government can get involved into IT affairs. It may be the only lasting effect we will all be forced to feel.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title MS-DOJ Talks Falter: So What?. You can follow him on twitter here or receive his weekly newsletter by subscribing here.