I have a hard and fast rule for myself: never install technology in a school if you can't teach someone there to run it. This might not seem like a hard rule to abide by, but it is. Novel and Windows NT servers are examples of technologies that break my rule.
To train someone to run these servers requires, first, that you start with a very technically oriented individual who is probably proficient in DOS or UNIX. Second, the person needs at least two rounds of training that will probably not be available locally and will cost about $2,000 per session, including travel and lodging. Third, between training sessions, the trainee needs a server to practice on, and that means one that is not currently operating a network. Finally, if you don't keep your newly trained expert happy, he or she will run off - such skills are highly marketable. Of course, you could rely on district-level expertise, but the folks in the central office are, by definition, not on site, and so this alternative also violates my rule.
If you believe in my rule as strongly as I do, it will affect how you go about providing electronic communication (e-mail, conferencing, file transfers, and so on). What I am discussing here is people-to-people communication, not World Wide Web browsing. Admittedly some Web browsers (e.g., Netscape and Microsoft Explorer) have e-mail features. Indeed, the February cover story in Byte does a good job of explaining the pros and cons of browser-based communications, and to my mind the cons outweigh the pros. I prefer the ease of administration and guaranteed deliverability of proprietary e-mail, so that is my subject here.
What I am about to explain is a solution that I am working on for a district of 15 schools. It's a sort of "grow your own" Wide Area Network (WAN) e-mail solution. In fact, it might scale up to larger districts of 50 to 100 schools, but I can't say for certain.
A great deal of software that runs on a server runs only on the server. By that I mean that, if you are at a workstation using this server software, the software is actually running on the server or the server has sent you a copy so you can run it on your workstation. This is a remarkably inefficient arrangement because one of the two machines - either the server or the workstation - has to do all the work. There is no cooperation. It's as if the pitcher throws a baseball, and then - like Bugs Bunny in a cartoon-dashes to home plate to catch it!
An alternative that's no better is the use of the Internet for communication. All communication on the Internet is address driven. Messages are encoded with an address and subsequently passed from server to server until, God willing, they arrive at their intended destination. To return to the baseball analogy, it is as if a player tosses the ball to another player, who then tosses it to a third player, and so on. Of course, any one of these players might drop the ball or pass it on to the wrong person.
In a client/server arrangement, the server software works hand-in-hand with software on your workstation. With client/ server e-mail, the server does what it does best (store and forward mail), while your workstation does what it does best (send, receive, and display the mail). Well-programmed client/server software is a joy to behold: it's fast, efficient, and nearly 100% reliable. It's like having the pitcher and catcher working together.
Over the years I've worked with a variety of e-mail software, and today I'm sold on FirstClass software from SoftArc in Markham, Ontario. FirstClass is the fourth-largest-selling electronic messaging software in the world, behind only Microsoft Mail, cc:Mail, and Groupwise. In addition, SoftArc is the only major messaging vendor to offer server and client software for both Mac and Windows operating systems. You can even mix and match clients and servers. For example, Windows users can attach to Mac servers. …