Why Microsoft Will Rule the World: A Wake-Up Call at Open-Source’s Mid-Life Crisis

By Jeffrey Carl

Boardwatch Magazine
Boardwatch Magazine, August 2001

Boardwatch Magazine was the place to go for Internet Service Provider industry news, opinions and gossip for much of the 1990s. It was founded by the iconoclastic and opinionated Jack Rickard in the commercial Internet’s early days, and by the time I joined it had a niche following but an influential among ISPs, particularly for its annual ranking of Tier 1 ISPs and through the ISPcon tradeshow. Writing and speaking for Boardwatch was one of my fondest memories of the first dot-com age.

In a Nutshell: The original hype over open-source software has died down – and with it, many of the companies built around it. Open-source software projects like Linux, *BSD, Apache and others need to face up to what they’re good at (power, security, speed of development) and what they aren’t (ease of use, corporate-friendliness, control of standards). They will either have to address those issues or remain niche players forever while Microsoft goes on to take over the world.

The Problem

There is a gnawing demon at the center of the computing world, and its name is Microsoft. 

For all the Microsoft-bashing that will go on in the rest of this column, let me state this up front: Microsoft has done an incredible job at what any company wants to do – leverage its strengths (sometimes in violation of anti-trust laws) to support its weaknesses and keep pushing until it wins the game. That’s the reason I hold Microsoft stock – I can’t stand the company, but I know a ruthless winner when I see it. I hope against reason that my investment will fail.

It has been nearly two years since I wrote a column that wasn’t “about” something, that was just a commentary on the state of things. Many of you may disagree with this, and assign it a mental Slashdot rating of “-1: Flamebait.” Nonetheless, I feel very strongly about this, and I think it needs to be said.

Here’s the bottom line: no matter how good the software you create is, it won’t succeed unless enough people choose to use it. Given enough time and the accelerating advances of other software, I guarantee you it will happen. You may not think this could ever be true of  Linux, Apache, or any other open-source software that is best-of-breed. But ask any die-hard user of AmigaOS, OS/2, WordPerfect, and they’ll tell you that you’re just wishing. 

Sure, there plenty of reasons these comparisons are dissimilar; Amiga was tied to proprietary hardware, and OS/2 and WordPerfect are the properties of companies which must produce profitable software or die. “Open-source projects are immune to these problems,” you say. Please read on, and I hope the similarities will become obvious.

For the purposes of this column, I’m going to include Apple and MacOS among the throng (even though Apple’s commitment to open source has frequently been lip service at best), because they’re the best example of software that went up against Microsoft and failed.

You say it’s the best software out there for you – so why does it care what anyone else thinks? It doesn’t, at first. But, slowly, the rest of the world makes life harder for you until you don’t have much choice.

In the Software Ghetto

Look at Apple, for example (disclaimer: I’m a longtime supporter of MacOS, along with FreeBSD and Linux). My company’s office computers are all Windows PCs; my corporate CIO insisted, despite my arguments for “the right tool for the job,” that I couldn’t get Macs for my graphics department. “We’ve standardized on a single platform,” is what he said. He’s not evil or dumb; it’s just that Windows networks are all he knows and are comfortable with.

Big deal, right? Most Mac users are fanatics. There’s a registered multi-million-person-plus community out there of fellow Mac-heads that I can always count on to keep buying Macs and keep the platform alive forever, right? An installed base of more than 20 million desktops plus sales of 1.5 million new computers in the past year alone is enough for perpetual life, right?

Sure, until that number is fewer than the number of licenses that Microsoft decides that it needs to keep producing MS Office for Mac. Right now, the fact that my Mac coexists with the Windows-only network at my office, because I can seamlessly exchange files with my Windows/Office brethren. But as soon as (which Microsoft could easily do by upgrading windows with a proprietary document format that can’t be decoded by other programs without violating the DMCA or something asinine like that) platform-neutral file-sharing goes out the Window (pun intended) … I’m going to have to get a Windows workstation.

Or Intuit decides there’s just not enough users to justify a Mac version of Quicken. Or, several years from now, Adobe decides it’s just not profitable to make a Mac version of Photoshop, InDesign or Illustrator … or even make critical new releases six months or a year behind the Windows version. I can still keep buying Macs … but I’ll need a Windoze box to run my critical applications. As more people do this, Apple won’t have the revenues to fund development of hardware and software worth keeping my loyalty.. And I’ll keep using the Windows box more and more until I finally decide I can’t justify the expense of paying for a computer I love that can’t do what I need.

“Apple,” you say, “is a for-profit company tied to a proprietary hardware architecture! This could never happen to open-source software running on inexpensive, common hardware!”

Open Source with a Closed Door

Let’s step back and look at Linux. A friend of mine works as a webmaster at a company that recently made a decision about what software to use to track website usage statistics. His boss found a product which provided live, real-time statistics – which only ran on Windows with Microsoft IIS. My friend showed off the virtues of Analog as a web stats tool, but they were too complicated for my friend’s boss to decipher. Whatever arguments my friend provided (“Stability! Security! The Virtues of Open Development!”) were simply too intangible to outweigh the benefits his boss wanted, which this one Windows/IIS-only software package provided. So, they switched to Windows as the hosting environment. 

There may come a day when you suggest an open-source software solution (let’s say Apache/Perl/PHP) to your boss or bosses, and they ask you who will run it if you’re gone. “There are plenty of people who know these things,” you say, and your boss says, “Who? I know plenty of MCSEs we can hire to run standardized systems. How do we know we can hire somebody who really knows about ‘Programming on Pearls’ or running our website on ‘PCP’ or whatever you’re talking about? There can’t be that many of them, so they must be more expensive to hire.” Protest as you might, there isn’t a single third-party statistic or study you can cite to prove them wrong.

If you ask the average corporate IT manager about open source, they’ll point to the previous or imminent failures of most Linux-based public companies as “proof” that open-source vendors won’t be there to provide paid phone support in two years like Microsoft will. 

I’m willing to bet that most of you out there can cite examples of the dictum that corporate IT managers don’t ever care about the costs they will save by using Linux. They are held responsible to a group of executives and users that aren’t computer experts, aren’t interested in becoming computer experts, and wouldn’t know the virtues of open source if it walked up and bit them on the ass. They want it to be easy for these people, and fully and seamlessly compatible with what the rest of the world is using, cost be damned. Say what you will – right now, there’s just no logical reason for these people not to choose Windows.

So maybe Linux users drop down to the point where Mac users have (still a significant number) – only the die-hard supporters. But how many of you Linux gurus out there don’t have a separate Windows box or boot partition to play all the games you like that aren’t developed for Linux because of lack of users/market share? Well, what about the next killer app that’s Windows-only until you use Linux less and less? Or the next cool web hosting feature that only MS/IIS has? Or as more MS Internet Explorer-optimized websites appear? 

I’m not arguing that Linux or BSD would ever truly disappear (there are still plenty of OS/2 users out there). I am, however, saying that as market share erodes, so does development; and, over the long run – if things continue on the present course – Windows has already won.

The main point is this: niche software will eventually die. It may take a very long time, but it eventually will die. Mac or Linux supporters claim that market share isn’t important: look at BMW, or Porsche, which have tiny market shares but still thrive. The counterpoint is that if they could only drive on compatible roads, and the local Department of Transportation had to choose between building roads that 95% of cars could ride on or building separate roads for these cars, they would soon have nowhere to drive. True, Linux/BSD has several Windows ABI/API compatibility projects and Macs have the excellent Connectix VirtualPC product for running Windows on Mac, but very few corporate IT managers or novice computer users are going to choose those over “the real thing.” And I’m willing to bet that those two groups make up 90% of the total computer market. 

You can argue all you like that small market share doesn’t mean immediate death. You’re right. But it means you’re moribund. One of the last bastions of DOS development, the MAME arcade game emulator, is switching after all these years to Win32 as its base platform – because the lead developer simply couldn’t use DOS as a true operating platform anymore. It will take time, but it will happen. Think of all the hundreds of thousands (if not millions) of machines out there right now running Windows 3.11 for Workgroups, OS/2, VMS, WordPerfect 5.1, FrameMaker, or even Lotus 1-2-3. They do what they do just fine. But, eventually, they’ll be replaced. With something else.

The Solution

All this complaining aside, the situation certainly isn’t hopeless. The problems are well known; it’s easier to point out problems than solutions. So, what’s the answer? 

For that 90% of users that will decide marketshare and acceptance, two things matter: visible advantages in ease of use, or quantifiable bottom-line cost savings. Note for example how Mac marketshare declined from 25% to less than 10% when the “visible” ease-of-use differential between Mac System 7 and Windows 95 declined. Or, look at how the cost of more-expensive Mac computers and fewer support personnel versus cheaper Windows PCs and more (but certified with estimable salary costs) support personnel.

Open-source software development is driven by programmers. Bless their hearts, they create great software but they’re leading it to its eventual doom. They need to ally firmly with their most antithetical group: users. Every open-source group needs to recruit (or conversely, a signup is needed by) at least one user-interface or marketing person. Every open-source project that doesn’t have at least one person asking the developers at all steps “Why can’t my grandmother figure this out?” is heading for disaster. Those that do are making progress.

Similarly, those open-source software projects that have proprietary competitors and are dealing with some sort of industry standard that aren’t taking a Microsoft-esque “embrace, extend” approach are going to fall behind. If they don’t provide (and there’s nothing against making these open and well-documented) new APIs or hooks for new features, Microsoft will when they release a competing product (and, believe me, they will; wait until Adobe has three consecutive bad quarters and Microsoft buys them). The upshot of this point is that open-source projects can’t just conform to standards that others with greater marketshare will extend; they need to provide unique, fiscally-realizable features of their own. 

Although Red Hat has made steps in this direction, other software projects (including Apple, Apache, GNOME, KDE and others) should work much harder to provide some rudimentary for of certification process to provide some form of standardized qualification. Otherwise, corporate/education/etc. users will have no idea what it costs to hire qualified support personnel.

Lastly, those few corporate entities staking their claims on open source should be sponsoring plenty of studies to show the quantifiable benefits of using their products (including the costs of support personnel, etc.). The concepts of “ease of use” or “open software” don’t mean jack to anyone who isn’t a computer partisan; those who consider computers to merely be tools must be shown why something is better than the “safe” choice.

Hosting FrontPage Sites on Unix Servers – Dealing with the Great Satan of Server Extensions

By Jeffrey Carl

Boardwatch Magazine
Boardwatch Magazine, November 2000

Boardwatch Magazine was the place to go for Internet Service Provider industry news, opinions and gossip for much of the 1990s. It was founded by the iconoclastic and opinionated Jack Rickard in the commercial Internet’s early days, and by the time I joined it had a niche following but an influential among ISPs, particularly for its annual ranking of Tier 1 ISPs and through the ISPcon tradeshow. Writing and speaking for Boardwatch was one of my fondest memories of the first dot-com age.

Ever since a version of FrontPage started getting bundled in with Microsoft Office 2000, FrontPage has quickly become the web site design tool of choice for people who enjoy being lectured by animated paper clips. If your hosting environment is Linux or *BSD, then FrontPage needs to be understood and dealt with.

FrontPage and How it Works

FrontPage is a simple GUI tool which automates the things that most basic web designers are looking for these days, including graphical page design, publishing their sites and CGI-type actions (forms, dynamic pages, etc.). Throughout the rest of this column, I don’t want to disparage what the creators of FrontPage have made – a truly easy, user-friendly program for the design of simple to very complex web sites – a real achievement.

But, for a FrontPage-created site to take use of all the easy-to-create “all-singing, all-dancing” features that make it such a hit with people who wouldn’t know an HTML tag if it crawled up and bit them, the FrontPage Server Extensions (FPSE) must be present on the hosting server. The FPSE are essentially Microsoft-built proprietary CGIs executed over HTTP – designed for Windows NT and Microsoft IIS, but ported to Unix and supported on Microsoft’s behalf by Unix porting house Ready-to-Run Software (RTR). This is where the trouble starts.

Can You Support FrontPage on a Freenix?

Supporting FrontPage on Unix is both a help and a hindrance to ISPs. It allows you to host sites for clients using FrontPage – and this faction is rapidly growing. It can provide you with a competitive advantage over ISPs that don’t support FrontPage sites.

The extensions are currently available for a number of platforms including FreeBSD and Linux (for x86 architectures only), and for a number of webservers including Apache, NCSA, Netscape and Stronghold (although only Apache will be discussed in this column). I’m sure that RTR has done a herculean task porting these server extensions to Unix, but the fact remains that this software is poorly documented and frequently difficult to troubleshoot.

The FrontPage extensions for Unix don’t allow you to support the full range of capabilities of FrontPage-designed sites. Active Server Pages (ASP) aren’t natively handled with the FPSE for Unix, and neither is native ActiveX nor ODBC/Microsoft Access database connectivity. 

You can, fortunately, look for outside support. Software vendor Chili!Soft (www.chilisoft.com/allaboutasp/) offers a Unix-native commercial ASP package, Halcyon (www.halcyonsoft.com/products/iasp.asp) offers a Java-based ASP commercial package, and mod_perl (perl.apache.org) with the Apache::ASP (www.nodeworks.com/asp/) module provides a free, Perl-based solution. Commercial ODBC resources are available at www.openlinksw.com, and open-source resources can be found at www.jepstone.net/FreeODBC.

The Pitfalls of FrontPage Extensions

Unfortunately, offering FPSE/Unix commits you to supporting what is, frankly, some occasionally very frustrating software. While security problems with FP-administered sites have decreased, it’s still not suitable for the truly paranoid (a full discussion would take up this whole magazine). The author.exe program that is part of the FPSE seems, on Unix, to eat up an unseemly amount of CPU cycles while it’s running. The .htaccess files that FrontPage installs for each of the directories in a FrontPage-enabled site may interfere with the server administrator’s security policies. And, in my experience, the FPSE will occasionally just stop working, with a reinstall required.

If you can’t find the free support resources you need, you can of course contact RTR for phone support ($245 per incident) or e-mail support ($195 per incident). And, if you don’t support it, FrontPage users are advised in the FrontPage/Unix FAQ to “find another ISP” (http://www.rtr.com/fpsupport/faq2000g.htm#7newISP). 

So much for “alternatives.” And the customer pressure to host FrontPage sites is quickly increasing. 

Before I go on to discuss how to support FrontPage on Unix, I should mention that there is another option – set up a server running Windows NT or Windows 2000. This has its own set of problems and complications (which could take up a book, not a column), but at least the FPSE work flawlessly. After two years and a multitude of problems supporting 50 or so FrontPage users on Red Hat Linux and FreeBSD, and seeking more scalability without headaches, I shamefully admit that this is what I ultimately did. Unfortunately, I think this is what Microsoft was hoping for all along.

Getting the FrontPage Extensions

For a detailed understanding of the installation process and some help with common problems, first visit the Server Extensions Resource Kit (“SERK”) page for Unix installation (www.rtr.com/fpsupport/serk4.0/inunix.htm). For a full list of the files included in an installation and their permissions structures, see www.rtr.com/fpsupport/serk4.0/apndx01.htm.

If you’re installing Apache on the server for the first time, you can use the apache-fp package (www.westbend.net/~hetzels/apache-fp/), available as a Linux RPM or through the FreeBSD ports collection, which integrates an Apache distribution with the Unix FPSE. If you’re installing on an existing Apache setup, go directly to RTR Software’s FPSE/Unix homepage (http://www.rtr.com/fpsupport/). Download the FrontPage 2000 SR 1.2 extensions for your platform (they’re backward-compatible with FP ’97 and ’98 clients), which come in a zipped or GNU-zipped tar file, as well as the shell scripts fp_install.sh and change_server.sh. 

The extensions tarball will be named like fp40.[osname].tar (version 4 is the FP 2000 extensions; version 3 is for FP ’98). The fp_install.sh script converts the results of the uname -a command to a $machine variable, and won’t install if the extensions tarball name doesn’t match the $machine name.

For a long time, it was necessary to get the extensions to install on FreeBSD by “hacking” the script. In this case, adding the line:

FreeBSD*)            machine="bsdi" ;;

as line 70 of the fp_install.sh script would get the BSDI extensions to install. This has been fixed if you download the most recent versions of the software.

Installing Unix FrontPage Extensions

The default install is into /usr/local/frontpage/version40, or in the directory of your choice, although it will create a link to the above. The installation script installs the FPSE, an HTML version of the SERK, the command-line administration tool (fpsrvadm.exe), the web-based administration tools (in the admcgi directory), the Apache-FP patch, and assorted server and site administrator support files. 

If you have already installed the version30 extensions, the script will move its currentversion symbolic link to point to the version40 directory while leaving the older version intact (actually a good choice, and one that many other software packages might adopt!). The installation script will also prompt you to upgrade the “stub extensions” (located inside each FrontPage-enabled host’s document root, linking to the central extension executables) for each virtual host which has had the older stub extensions installed.

While installing, note that each site’s FrontPage username and password (used for administering their site through the FrontPage client) have no relation to their Unix username and password. For security’s sake (unless the users will be administering their sites through secure server access), it is advisable to make these username/passwords different from their Unix user/password counterparts. Note that if each of your virtual hosts are associated with different Unix users/groups, those “subwebs” should be owned by the Unix user/group of the site maintainer, or they will be unable to administer their site properly.

Next, run the change_server.sh script to automatically replace the existing httpd daemon with a FPSE-supplied one which has the FrontPage patch/module installed (with only the mod_frontpage module and a few other basic modules compiled in; it moves the old one to httpd.orig). The script further creates a suidkey file, used when the FPSE exercise their suid (“set user ID”) bit to make root-level modifications. It also prompts you to upgrade any virtual hosts if necessary.

The Apache version used with the current extensions (as of this writing) is 1.3.12. Note, however, that using an older version of the extensions may replace your Apache daemon with an older Apache daemon. If you would like to compile your own Apache daemon instead of using the change_server.sh-installed one (recommended), you may wish to download the Improved Mod_Frontpage (home.edo.uni-dortmund.de/~chripo/) and then follow the installation/compilation directions listed at www.rtr.com/fpsupport/serk4.0/inunix.htm#installingtheapachepatch. If the patch fails, check out the info at home.edo.uni-dortmund.de/~chripo/faq.asp). 

Administering FrontPage Sites

For the server administrator, the command-line tool fpsrvadm.exe is your primary interface. This tool allows you to install or uninstall FPSE for virtual hosts, set authoring options for them, set directory/executable permissions, chown files, and create or merge subwebs. Running fpsrvadm.exe without any arguments brings you to a GUI-like interface; or, you can run the program directly with command-line options which are detailed at www.rtr.com/fpsupport/serk4.0/adfpsr_3.htm.

When adding FPSE to virtual hosts, choose Apache-FP for “server type” unless you have chosen not to install the FrontPage patch. During a host installation, “stub extensions” will be installed for the selected host, and its executable directories aliased appropriately.

Through fpsrvadm.exe, you can also run a “check and fix” option on existing hosts. While this option won’t tell you anything other than whether the extensions are installed or not (and which version), it can frequently be a valuable tool. When running a check or installing new virtual hosts, be sure to specify the port number (e.g., www.somehost.com:80) or it won’t be recognized.

If e-mailing FrontPage forms fails, be sure to edit your /usr/local/frontpage/we80.cnf file and add the line: 

SendMailCommand:/usr/sbin/sendmail %r

…replacing the above path with the correct path to your MTA of choice. Otherwise, FrontPage forms will not be able to send e-mail. I’m not sure why this isn’t part of the default installation, but it isn’t. Also, note that frequently users may use FTP rather than use their FrontPage client to upload files to their site. A common problem is that if an entire directory is uploaded by the user via FTP, it may overwrite the FPSE located in that directory, and it may be necessary to reinstall the FPSE for that host.

Documentation and Support

Your official first stop for documentation will be the “official” version of the SERK at officeupdate.microsoft.com/frontpage/wpp/serk/. The SERK is required reading for any sysadmin to understand FrontPage, especially those with training in Unix and not Microsoft systems. Unfortunately, the FP 2000 SERK (the FP 98 SERK did not share this problem) is the first Unix documentation package I have ever encountered which does not even mention the terms “problem” or “troubleshooting.”

For real-world administrators, your un-official first stops will be the RTR FrontPage 2000 FAQ (www.rtr.com/fpsupport/faq2000.htm) and discussion board (www.rtr.com/fpsupport/discuss.htm). While the discussion boards aren’t always much help, the FAQ is absolutely essential, answering most of the common questions that can make the difference between supporting FrontPage and chewing the Ethernet cable off the server in frustration. I’m not sure why elements of the FAQ haven’t been integrated with the SERK (by the way, would a few man pages be too much to ask?). It is essential that, because of how disorganized much of the FrontPage/Unix documentation is, you should scour everyavailable resource before considering a problem unsolvable.

Part of my problem with the Unix FPSE is that they use Microsoft’s seemingly proprietary way of describing things, which makes life difficult for Unix administrators. For example, the collections of a user’s web pages are normally known as a “web site,” which has a “document root” and may be a “virtual host.” In the Front Page Mirror Universe, the evil Captain Kirk has a goatee, and this is known as a “FrontPage web,” with a “root web” and “virtual webs.” To use my favorite acronym, “WTF?”

There is a newsgroup available at microsoft.public.frontpage.extensions.unix. However, a quick perusal of this newsgroup’s messages over the past several months shows that the postings appear to be mainly problems and questions – without many answers. There was a FrontPage/Unix mailing list ([email protected]), but as of this writing [email protected] no longer seems to be responding for subscriptions. I recommend searching Google (www.google.com) for FrontPage web resources.

Conclusions

Supporting FrontPage websites on Freenixes is very possible, and for basic purposes, it works very well. However, be prepared to do your homework, and know that it may not be easy. Administering a web server always requires serious research and work; depending on your tastes, dealing with FrontPage on Unix may require too much.