The clock is ticking. Are you ready?
In just a few weeks, Netscape will either do the unthinkable or make its game-saving throw, depending on your point of view. On 31 March, the company will make its browser free to the public and, in a bold move, release the source code for Navigator.
When the news broke, the Net developer community went wild. "Now I can fix all those stupid HTTP bugs," said a friend who stays awake at night worrying about such things, "and all those crashes under Linux, and the keep-alive stuff...." He wasn't the only one. Designers got chills thinking about a solid CSS implementation, and XML geeks started vying for position with their particular parsers.
Overall, it really is good news. The Net in general - and the Web in particular - was cut on a tradition of widespread collaboration using free software. Just look at Apache, Linux, sendmail, Perl, and the whole GNU software copyleft philosophies. Look back just a few years ago - before the marketing-driven landscape of Web standards emerged - and you'll find the Internet Engineering Task Force, a group dedicated to developing and keeping the underlying specifications of the Internet. And that group, along with others, was always quite fond of proclaiming the value of working code over promised specs. So the best and the brightest can now get busy making Netscape Navigator the classic example of collaborative software development. It won't be easy, of course, but it just might be a winner. Look, for example, at the Apache Web server project. It has been going on for years now, with scores of individuals working to make it the best possible solution for serving HTTP. It has paid off, too, earning this free piece of software an amazingly large chunk of the Web server market.
One reason the Apache project was so successful is that it started with a strong foundation. Large-scale collaboration starting from scratch is nearly impossible. There has to be a vision, an idea, a base upon which to build. Apache had the basic NCSA HTTP server, which was improved by a small group of people into a fast and stable product before it was opened up to public development. Same, too, for Navigator. A lot of work has been done and a lot of effort has gone into making it a great browser (albeit one with some significant rough edges).
One of Netscape's big challenges will be in undertaking the huge organizational effort of managing such a project. Every software effort mentioned above includes at its core an individual or small group responsible for maintaining the "current version." But this is significantly more difficult for widely used consumer client software like Navigator. Netscape will surely try with difficulty to control the project after its source code is made public.
But let's consider for a moment what will happen if Netscape does lose some control: Suddenly, thousands of versions of Navigator will exist, some with rendering bugs fixed, others with all the cookie code hacked out, and still others with changed default values for, say, the way images align in tables. Content providers and Web designers won't rely on their pages looking the way they wanted. Why, they will be forced to do the unthinkable. They'll be forced to rely on standards!
Netscape set the default visual standards years ago by being the only player in the game. The lack of competition made us lazy - we assumed that the weird way Navigator rendered things was how Web content was supposed to look. When engineers were designing new browsers - like Microsoft's Internet Explorer - they had to spend valuable development time adding Netscape's bugs to their browsers so everything would look fine. Now, with excellent browsers like Opera on the scene, designers complain that their pages are no longer perfect.
We need a new definition of "perfect," and an open Netscape may just lead us there.
If you'd like to follow the development as it happens, keep your eye on Netscape's Mozilla.org site or the grassroots Openscape. For more background on open source code projects, I heartily recommend the well-written analysis "The Cathedral and the Bazaar" by Eric S. Raymond.
This article appeared originally in HotWired.
