Agenda-Free Computing

Last week at SD 98, I hosted a session on the use of Linux as a network services platform (the PowerPoint slides can be downloaded from here). This was a fun talk to give as I happen to be a big Linux fan, and also because I got the chance to rail against the attending developers for not supporting the platform enough.

Hey, Wait! Before you break the DEL key off your keyboard, this stuff is important. While Linux may not be of that much relevance to you personally, many of the lessons learned from The Great Linux Experiment are applicable to other technologies. One day, these concepts are going to directly affect your bottom line.

These lessons don't have anything to do with operating systems. Well, Linux teaches us a lot about operating systems and how they get accepted, but that's not what I'm talking about. The most important lessons that Linux has to offer have to do with user-driven software, and what's possible when corporate agendas are removed from the development process.

Most of these lessons aren't new. User-driven software has been around for decades, in a variety of forms. A good many of the UNIX utilities in use today are a direct result of cooperative development based on open source code. Even the Internet's success can be traced back to a need for vendor-independent communications, arguably the most fundamental aspect of IP in general.

Yet, as more companies try to emulate the Linux model (witness Netscape's efforts with Communicator), many of these lessons are being rediscovered. Companies are looking for ways to advance the adoption of their technologies, and open development environments seem like a good way to do it. That may be true to a certain extent, but not entirely. If history teaches us anything it's that the lessons ignored will only have to be re-learned, generally in much more personal ways.

There are two absolute concepts that need to be learned from Linux: user-driven software works, and user-driven software doesn't work. How these seemingly contradicting facts play out is what makes the whole thing so fascinating.

What's Good About Linux

First of all, Linux works, and it works very well. For example, here at EHS Company Global HQ, we run almost all of our critical network services on Caldera's OpenLinux Standard. This includes DNS, DHCP, SMB/WINS, NIS/NFS, LDAP, IMAP/POP3, and a variety of other services.

The amazing thing is that all of this is running on an old 25 megahertz 386 with only 16 megabytes of RAM. There's no way we could run these services on this computer with any other operating system. I'm not suggesting that you try to run your firm's network services on an old 386. Rather, I'm saying that it's an option not available with many other platforms.

If you're going to be supporting hundreds of users or hosts, then you would probably want to use a higher-octane system. For that, you can get implementations of Linux that run on Sparc, Alpha, or PowerPC. But as we've seen here, Linux is also capable of being scaled downwards, allowing it to run on an old 386 if that's what you want. There's even an effort to get Linux working on 3Com's PalmPilot. While you wouldn't want to run any servers on it, the sheer fact that it can be done illustrates the high level of portability that Linux carries.

This bi-directional scalability is the envy of the industry. While there are many operating systems that run on multiple hardware platforms, very few have the wide variety of ports available for Linux. The reason for this is simple: Linux is an end-user driven operating-system that doesn't have a vendor with economic concerns to hold it back.

So for example, while SCO has been able to build and champion UnixWare on Intel, their ability to go beyond this platform is limited by the costs of developing and supporting these ports. Where is UnixWare for Alpha, never mind the PalmPilot? Similarly, Microsoft can champion NT on Alpha all day long, but the roster of orphaned ports is longer than the list of supported ones. Remember NT on MIPS? NT on PowerPC? Heck, you can't even get a version of NT that runs on a 386 anymore (a 486 is the minimum system requirement with NT 4.0).

Because system vendors have to pay for this development work, there is a point where it becomes economically unfeasible to do so. Linux doesn't have a Linux, Inc. making these decisions, so platform availability is left to the user community instead. Want Linux for your Wang VS system? Here's the source code; knock yourself out.

This is the real crux of the matter, at least when it comes to vendor-independent technologies like Linux. Without a vendor making crucial decisions, the technology is allowed to grow according to the wants and needs of the user community. Another good example of this is TCP/IP, of course. The IP protocol has been made to run on everything from carrier pigeons to SONET, all as a result of there not being an Internet, Inc. to hinder the effort.

This model offers several significant impacts for the user community. One of my favorite examples here is authentication. Since nobody is dictating what authentication services must be used by the OS, any authentication service can be used. Want to use /etc/passwd for everything? Fine. Want to use Kerberos instead? That's okay, too. If you wanted to use LDAP, NDS, or LAN Manager domains for authentication, you certainly could, assuming you develop the interfaces.

Contrast this to the authentication services provided by vendors of other operating systems. Trying to get a vendor to open their authentication services is problematic, to say the least. For example, Novell doesn't want to expose NetWare's password APIs, so nobody has been able to develop a Kerberos server that runs on the NetWare platform. While I appreciate their concern, I would rather not have them making decisions about my company for me. With Linux, I get to make my own decisions.

The lessons we can learn from all of this are simple. People will use free technology, regardless of the limitations, as long as it is functional. Not only will they use it, given the chance they'll drive its adoption into areas you couldn't even begin to imagine, modifying it to fit with platforms and services you may not even consider to be suitable. And not only will they drive the adoption process, they'll grease the tracks, cut the brake lines, sink the anchor and do anything else they can to accelerate this adoption.

All of these benefits are applicable to any source-driven technology, and should also be inherited by Netscape's effort to put Communicator into this realm. We've already seen that Communicator works, and we've already seen that it's portable. Now that the source has been made available, we'll likely see it on more platforms than Netscape could have or would have done on their own (c'mon, gimme versions for Wang and the PalmPilot!). We'll also likely see Communicator become increasingly independent of Netscape's own favored technologies, with implementations that support Kerberos as well as X.509 certificates, whether Netscape wants this or not.

What's Bad About Linux

Lest I be accused of zealotry, we also need to talk about the dark underbelly of user-driven software. The truth is, there are many shortcomings to Linux and other source technologies. The two biggest problems are accountability and availability.

First, availability. As I mentioned earlier, we run most of our network services on Linux, but we don't run all of them on it. The reason for this: we just can't get Linux implementations of all the services that we use. Sure, I can find bitchin' LDAP and IMAP servers, but I can't get versions of Cold Fusion, Oracle, or many other commercial products. Come to think of it, I can't even get Netscape's SuiteSpot line of servers for Linux. Without these, I'm forced to keep a system running NT dedicated to these services.

Yes, there are Linux counterparts to these products, but I don't want to use them. I want to use products that I can get support for at three o'clock in the morning. In other words, I'm looking for accountability. I cannot afford to run the revenue parts of my business on unsupported software. Without accountability, no corporation with any sense whatsoever is ever going to commit to Linux in a big way.

To be fair, there are several commercial products available for Linux already. In the database space for example, there are versions of Software AG's Adabase D and Solid Technology's Solid Server. However, unless you're already using these products, you probably aren't interested in rewriting all of your business logic and rules into yet another database system. These companies will definitely have an advantage with new clients who are not yet married to Oracle or Sybase, but the same is true of Microsoft's SQL Server and Windows NT.

To put it bluntly, Linux will not succeed as a mainstream corporate platform without the support of mainstream vendors. Whereas the Macintosh, OS/2, NetWare and all other platforms live and die by application availability, the same is true with Linux. Without Oracle and Sybase, it will never succeed. Companies can do without Linux; they can't do without their data.

One thing that the bazaar-model fans have conveniently chosen to ignore is the fact that supporting a product is just as important (and more expensive) as writing it in the first place. Remember that even TCP/IP didn't succeed in mainstream markets until companies like Cisco came on the scene with commercial implementations that appealed to mainstream customers. Where are all those freeware, software-based routers now? Without a cathedral-oriented vendor to support a technology, it's acceptance will be seriously limited.

The lessons we see here are also applicable to Communicator, of course. Will Netscape support Communicator for Rhapsody, or will they leave end-user support up to the development community? Without support, nobody will use it for mission critical operations. And will third-party vendors such as Macromedia and RealAudio develop plug-ins for Communicator on all of these different systems? I doubt it very much.

In truth, all of this may be moot, as Communicator is just a client application. All of these platforms will benefit by having another browser available to them, whether it's used for mission critical work or not. It's not like we're talking about database servers. Still, the lessons we learn from Linux and IP are applicable and relevant, and mustn't be ignored.

Getting Vendors to Support Linux

So why don't commercial vendors build versions for Linux? I suppose it comes down to there not being a VP of Marketing at Linux, Inc., out pushing the platform, cutting deals. As one Oracle representative told me, "We already support 120 platforms, why should we support another one?" Obviously, nobody from Linux, Inc. has come by with the slide projector.

My own thoughts on this are fairly simple: by Oracle and other vendors adopting Linux for their own purposes, they have the opportunity to ship highly-optimized implementations that suit their needs and no-one else's. Essentially, Oracle can ship a version of Linux that uses the services and features that they want, without having to appease some OS vendor's agenda in the process.

Another dimension to this problem has to do with the wide availability of Linux itself. Is Oracle supposed to ship versions of Workgroup Server for the 386? What about for Alpha and PowerPC? What about for the PalmPilot? The thing that killed NT on MIPS wasn't that it was too hard to maintain, but that the lack of availability of commercial products made it an unrealistic platform for the buyers. Without products for NT on MIPS, who cared about whatever benefits it may have offered? The same issues apply to Linux.

However, this time Oracle would indeed benefit by making their software available on as many of these builds as possible. By showing the OS vendors that they aren't really needed, application vendors gain better negotiating positions if nothing else.

Further, I'm of the opinion that it shouldn't just be the Oracles of the world that do this. Any vendor with a UNIX product ought to build a version for Linux, and they should sell it, and they should provide customer support for it. They should absolutely not give it away. It is in everyone's best interest to do so. If you still don't understand why, call me and I'll explain it in person.

That's all for now.

Regards,

Eric A. Hall
Head Honcho, EHS Company

Written by Eric A. Hall.
Copyright © 1998, EHS Company. net.Opinion is a trademark of EHS Company. All rights reserved.