Finding qualified IT people is tough--staffing qualified Unix pros, and keeping them, is even tougher. While most mainstream Unix administrators will adapt to Linux's layout pretty easily, NetWare and NT administrators will be much slower to embrace it. Add a bunch of VARs trying to sell Linux with very little experience, and you have the makings of a real mess.

The recently formed Linux Professional Institute (LPI) is trying to address the education issue. Composed of members of the Linux community, such as Caldera, Red Hat, SuSE, Slackware and Pacific Hi-Tech, among others, the LPI hopes to standardize training and certification efforts for the entire Linux industry. Modeling its program after certification efforts, such as the CCIE (Cisco Certified Internetwork Expert), CNE and MCSE, the LPI aims to create and brand the LCE (Linux Certified Engineer), and hopes to complete the first round of certification tests by the end of September.

While this begins to address the staffing issue, it brings some other challenges to light. For example, in our tests of various distributions, we resorted to all command-line configurations. It wasn't a problem for us because we've been using Linux for years, but it would be for any Linux novice. For example, if our experience had been limited to using the "LinuxConf" package (a Web-based system configuration tool found in Red Hat's distribution) for system administration, and we suddenly had a new version of Caldera's OpenLinux running COAS thrown at us, how easily would we be able to adapt? From a training perspective, do you prepare administrators for one distribution, all distributions, or the lowest common denominator? Multiple design paths with multiple distributions may provide for more options, but can also create some interesting problems. And this could be compounded by the competitive nature of the current Linux distributors. In their current state, the different packages simply allow for a greater variety. However, should Linux vendors continue to plow forward with their own plans, it could get ugly fast. Much as the IETF plays a role in protocol standardization, the Linux community is in dire need of independent standards bodies.

A Fork in the Road
The biggest factor behind Linux's rapid evolution lies in its open source code. Open source has also received a fair amount of attention lately, and at this point conventional wisdom has swung from "Hey, if it's free it can't be good" to "If it's open it might be more mature." But what does this mean for the average network administrator?

Well, for starters, it places the administrator in the driver's seat. For example, consider the problems we had with a Linux driver for an SMC Ethernet card. During our tests, a server was using an SMC 10/100 card that insisted on switching into 100-Mbps mode even though it was plugged into a 10-Mbps segment. We found no help at SMC's site, so we turned to AltaVista. Within minutes we were looking at the home page of the driver's author--complete with updated driver source, tips and frequently asked questions. We found the answer to the problem, downloaded the latest driver and learned a few things while we were at it.

On the security and patching front, Linux turn-around times are often dizzying. Anyone on the BUGTRAQ security mailing list will attest to the rapid creation of the "ping-of-death" fix: It took less than 12 hours. This is open source's real triumph: Organizations can fix problems they discover themselves, pay a source such as Linuxcare to fix it or wait for the Linux distributor to send out an update. In the end, the organization--the Linux user--is in control. This is the root of open source: The evolutionary process is all-encompassing.

Of course, the Linux coding movement is not problem-free. One obstacle is the threat of fragmentation and code forking. Many Linux users are concerned about the gray area between GNU-protected source and what distributors have been packaging with that source code. Some are skeptical about Red Hat's commitment to a unified approach to Linux. Red Hat has been reluctant to participate in the Linux Standards Base--a project to unify "base" Linux distributions. It has also formed its own training and certification programs independent of the LPI initiatives.

On a similar level, Caldera is busy working on more robust file-system and clustering solutions for its distribution. While Caldera officials state the company intends to release some of its work down the road, it is not an immediate priority. If Caldera produces a clustering technology that will run only on OpenLinux while some other distributor develops a journalized 64-bit file system that only runs on its distribution, we will see the fragmentation that hit the Unix community smack the Linux community even harder.

But Linus Torvalds and his crew of approximately 50 kernel developers will continue to pound away at build after build of the kernel, regardless. While distributors jockey for position, close in on larger sales and figure out how to capitalize on essentially a free revolution, the Linux phenomenon continues to evolve.

Greg Shipley is a Chicago-based consultant and contributing editor for Network Computing. Send your comments on this article to him at gshipley@neohapsis.com.