4. XXX-1998 (let's say it's 1-Oct-1998): Declare the trunk stable, tag it with a blessed CVS label that anyone can use to derive product from (particularly, but certainly not exclusively, Netscape for Communicator 5.0), and then:5. XXX plus 1: open the tree to next-gen layout, aggressive modularity, other changes. I should emphasize that the difference between 1-Sept and this date cannot be many months, or we're doomed.
Mozilla 1.0 shipped June 5, 2002.
If we do only "the browser thing" [...] we are likely to be irrelevant in approximately five years. Not unused, but trailing-edge; not built upon as a platform, not invested in even as a hedge.
Draw your own conclusions.
GMail
Apparently GMail uses a ton of javascript and frames, and feels more like a client side application and a web page. What pisses me off about this isn't anything Google has done, in fact quite the opposite. Massive amounts of client-side javascript was my vision for the future of web applications as a young punk back in '96. A good example is this demo, which has worked since Netscape Navigator 2.0 and the concurrent version of IE. Of course, we all know know what has become of that vision - basically nothing, since a combination of javascript buginess and general fear of doing real software has relegated javascript to mostly ornamental use on web pages.
I hope that my demo at least helped inspire someone working on GMail. My own youthful enthusiasm for doing javascript got squelched by beurocratic mismanagement in the company I worked for at the time. Earthweb, later to become one of the most grotesgue dot come IPOs and flameouts of them all. I hate seeing hustlers get rich.
It's good to at least see that my original approach had some merit. Just kidding about the last eight years of web development, kids. The approach of ambitious but naive hackers which we had from the very beginning was the right one.
Puzzle Extension
Wriggle puzzles have a fascinating property - It's possible to extend a puzzle to make another puzzle which is strictly harder, because any solution to the harder puzzle also works as a solution to the easier puzzle. This applies to worm extension, addition, and fusing. Sokoban has a similar property under the addition of new walls. It's interesting to find places in the standard sokoban levels where a wall could be added without making the puzzle impossible.
A very interesting poorly behaved game can be derived from this property - two players alternately extend a shared puzzle until one of them challenges the other to find a solution, and the other player either comes up with a solution and wins or fails to do so and loses. Interesting tactics include making a particular region of the puzzle only solveable in a tricky way which you already know, so there is a solution but it's computationally difficult to find.