More Linux vs. Microsoft (vs. MAC)
In the previous article, I noted that the change in the computing and network environment over just the 3 years from when we left iSTAR to when we joined Lineo meant a completely new set of problems despite the fact that we were dealing with multiple offices and had the Internet at our disposal. Some of the problems we faced were not directly related to which operating system we used on our desktops or servers, but they did influence decisions in that regard none the less.
The problems included the typical ones of different versions of the various word processing packages and spreadsheets we all used as well as others. They also included the problems presented by trying to extend the LAN concept to remote offices, something that was only attempted in previous years by very large companies; and with limited expectations and success at that.
In the intervening 3 years (between iSTAR and Lineo) the internet had grown up quite a bit and this actually showed up as one of the major problems fairly early on. At an early organization meeting we were presented with a plan to link the offices via leased lines and frame relay, with a single gateway to the Internet at the head office. In iSTAR's time this would have been a reasonable suggestion, especially since the Lineo offices were spread throughout the world instead of being all in one country. To say that those of us from offices outside of Utah (where Lineo's head office was) were incredulous would be putting it mildly!
The circumstances into which this proposal was made were radically different from those even a year or two earlier:
| The companies brought together were staffed by individuals used to direct access at high speed to the Internet | |
| The product that Lineo was based upon (Linux) was the largest distributed software development project in the world, and it was tightly integrated into the Internet environment | |
| Things like e-mail attachments had grown from a few thousands of bytes to megabytes, especially between developers and customers of software vendors. | |
| Each of the companies that Lineo purchased had their own web sites, ftp sites, software repositories, e-mail systems, and expertise in these areas; and was not about to take a step down in capabilities in the integration process. |
These were the major points, but they were exacerbated by the proposal to funnel all the Internet access through a measly T1 (1.5 Mbps) connection when many (most) of the software people in the other offices had cable or ADSL connections which ran faster. Admittedly the people in Australia and the far East were running mostly on 56K ISDN or lease lines to their local ISP, but the majority of people were in places where their offices had their own T1 or DSL connection, and the individuals might have faster connections at home!
Even the lower bandwidth might have been ok if it were not for the much higher propagation delay (the time it takes a packet to get from one computer to another) the routing of all the traffic through the one link would have meant. While propagation delay doesn't appear on the surface to affect things much if you are not actually interacting directly character by character with the computer at the other end, it actually slows things like web browsing substantially, even if the total bandwidth is high and the link not saturated.
High propagation delay causes affects the start-up time for each file transfer. Each such start-up consists of at least a 4 part conversation between your web browser and the server at the other end, and there can be literally hundreds of such start-ups for a single page in some cases; one for each graphic and segment in a complex page such as a portal page. A 1/2 second propagation delay (500ms) which is what we were likely to end up with from some offices, would mean 2 seconds (4 parts, each taking 1/2 second minimum to even start) before anything even showed up on a screen, and with many browsers and servers set to only start a maximum of 4 such conversations in parallel, a complex page might go from taking a few seconds total where the delay was 10-100 ms, to taking ten times as long or more - even minutes!
The only saving grace the design would have had was that it was LAN friendly - it was a known quantity and a private link that could have connected all the office's LANs together without separate firewalls and routers. In a perfect (and coherent/homogenous) LAN environment this would have been heaven. With all of us using a mix of versions and operating systems it would have been worse than what eventually happened because the expectation would have been that things would "just work" together. As it was, since we didn't just hook all the LANs together at one time, the expectations were less and we ended up looking for other solutions to the various problems.
Head office had Lotus Notes and used Microsoft Office for documents in most cases. In fact, administration in all the offices used MS Office almost exclusively, so from that point of view things worked fairly well. The problem was that head office had Notes and shared files in that way, and nobody even told the rest of us what files were available, let alone how to get them. It turned out that there were in fact ways to get them - just not obvious or documented.
On the other hand, most of the software people used Linux (for obvious reasons) and so sending out documents to them was problematic. Many either didn't have, or wouldn't be bothered using, access to Office or any other Microsoft product. The fact that they were in the Linux development arena initially was ignored as an aspect of the potential integration of the various offices; nobody thought that there would be active resistance to the use of non Linux tools! And this in a Linux company!
What should have been the "lowest common denominator", e-mail, turned out to be the biggest problem! Even discounting the format of attached documents, the fact that initially head office, and eventually the 3 West coast offices as well, did all their e-mail using Notes meant that those outside this clique either got a poorly formatted version in a Windows mail program (we eventually got Notes clients) or couldn't read it at all in a text-only mail client under Linux. Yes, there was a web interface of sorts (apologies to IBM, it may simply have been the implementation) but it was missing some critical elements and proved to be next to useless when trying to use from Netscape or Mozilla under Linux. It also meant adding yet another mail box to the list of those to check for incoming messages, and bypassed the recipient's favourite filter and filing programs.
The saving grace for sending documents turned out to be Adobe PDF and the use of Rich Text Format for saving widely disseminated documents. Both of these formats are well served on Linux and Windows.
The saving grace for sharing ideas and such turned out to be a very interesting facility of the Web called a WIKI; essentially a set of web pages that anyone with access could modify and extend with just a simple web browser - from anywhere, at any time, over the Internet! By building a WIKI (and in fact several of them eventually), and putting it within the Lineo Intranet (secure, authenticated, authorized but accessible from anywhere on the web if you had the right ID and password) we increased the interaction of the various R&D, sales, marketing and even administration groups to an incredible degree.
The next article will deal in more detail with the various integration puzzles we solved.



What's Related