Can the Samba Story be Retold?by Andy Oram
Finally, the open source community is taking .NET seriously, and they're starting to tremble harder than an office building in a Seattle earthquake.
On March 19, an announcement of HailStorm -- a new Microsoft service for providing standardized data exchanges between e-commerce sites and customers -- hurtled down from on high, and Microsoft critics worry that Microsoft will use it to essentially put up a toll booth on every data highway. But long before this, many well-placed observers warn that .NET could crush everything in its path.
Open source advocates ignored it, sneered at it, claimed that Microsoft will never get it right. But so what? Maybe it should be right. If it's a good idea, someone should do it with open source software too.
A precedent to learn from
Let's go back several years to another attempt at world domination, when Microsoft positioned Windows NT systems to act as file and print servers on corporate LANs. The communications protocol they were using at the time (invented by IBM and 3COM) was called Server Message Block (SMB), later enhanced to Common Internet File System (CIFS). It had some problems, but it served their purposes, and soon Windows NT seemed ready to render Unix obsolete in any environment based on Windows PCs.
Brewing a HailStorm -- Rael Dornfest has been digesting Microsoft's HailStorm announcement. Is it Microsoft's most ambitious land grab ever, or a shocking move towards open standards?
Windows NT, and now Windows 2000, are certainly widespread. But thanks to some clever clean-room engineering by Andrew Tridgell, Unix and Linux also came out better than ever. Tridgell, of course, is the hacker responsible for Samba, an SMB-compliant set of Unix daemons. He wasn't thinking about providing an alternative to Microsoft products when he developed it, just about trying to connect to a proprietary vendor's system (not Microsoft).
But once word got out about Samba, people found their bottom lines benefited from the low cost and reliability of a Linux or Unix solution in the back office. The result is (as Microsoft keeps saying in court) that Windows 2000 has to compete with powerful Linux and Unix servers in Microsoft's core markets.
Another lesson about Samba is that sometimes you can make great inroads by staying away from religious wars. While members of the Samba development team are by no means shy in complaining about Microsoft products and practices, they follow every Microsoft twist and turn zealously with a "Let's get this working" attitude. The results of their hard work make things better for everybody: Linux enthusiasts find a home in corporations while Windows users get good file servers.
Applying the lesson
Now we face .NET. If it's everything Microsoft wants it to be, it will allow programmers to write in any language they want and expose functions easily as Web services. What effect might it have on the computer industry?
- Being an easy-to-program and versatile environment for distributed computing, it might become a standard platform for a great many next-generation applications.
- Because .NET is cross-language and (potentially) cross-platform, people designing new functions might automatically make them .NET components where they would now offer them as libraries, Java packages, etc.
- Thousands of new services might be offered only as .NET components.
- Microsoft might benefit the most from item number 3 and maintain its domination of end-user applications, although perhaps not as exclusively as Microsoft Office does now.
Not only could everybody eat Microsoft's strawberries and cream, but they might like it. Programs might be updated more quickly, users be freed from upgrades and downloads, programmers write in whatever language they like to write, buffer overflows vanish like a bacillus in a vat of penicillin, and eager-beaver scripters customize their interaction with services through SOAP requests.
(Sideline security musing: what happens if some company offers a pay-per-use service, perhaps like Microsoft's new HailStorm, and someone embeds it on their Web page? At 2:00 some morning, a malicious or buggy program issues requests for that service at the rate of one thousand per second. The Web site's administrator walks in at 9:00 AM to find a bill for five years' earnings. How does .NET protect against this?)
What's required now
Can the open source community afford to wait and see whether Microsoft is unable to make .NET work? When something is as important to Microsoft as .NET, it works (eventually). But why should open source developers wait? The .NET dream provides intriguing benefits. The specifications are open, so open source developers should get onto sourceforge and reproduce them now -- the whole Common Language Interface and runtime engine.
Lots of the open source pieces are already in place. Java is cross-platform, Apache adapts marvelously to new modules and functionality, open-source scripting languages support SOAP and XML-RPC, compiler back-ends routinely generate code for different platforms, and the CORBA specifications (should we need to hoist such a heavy piece in place) provide name services and security.
What this will mean is that open source can win the stealth game. If anyone wants a convenient web service, the open source community can lobby to make it run on Linux or BSD using the open source CLI. If somebody finds the .NET environment or the operating system behind it to be buggy, he can quietly substitute Linux, as so many sysadmins did in the Samba story, and continue work as usual.
What we need is a pioneering spirit yoked to a serious concern for what individuals and businesses want. The old daemon may be on the way down. The component may be the wave of the future. We should at least have our surf boards out in case this is true.
Return to the O'Reilly Network Hub.