There seems to be some confusion. No one is proposing that Mozilla and GNOME implement "XAML" -- it's a pre-release, proprietary moving target. Also, the Mono project is not part of GNOME.
What everyone wants, what even Microsoft is "reacting" to, is the graphics capabilities of modern PCs, the ease of UI and graphical design inherent in XML declarations and managed code driving a layout and rendering engine, and the current failure of web standards to marry the two. MS can cut through the red tape and make a UI and graphics language that rivals XUL and Macromedia's Flex markup language combined.
Matching MS's every move is stupid, and it wasn't what anyone proposed. Building a competitive graphics and UI toolkit together was on the table, because otherwise the open source alternative to things like XAML (or MXML) is fragmented and weak.
BTW, Active X plugins are supported in Mozilla, conditionally (whitelist empty by default). Too many sites use Windows Media Player, and it requires Active X plugin glue. Last I heard, http://www.gamespot.com/ still showed hot new games' cut-scenes using WMP only.
You should know that mozilla.org does not endorse Active X, but Netscape/AOL funded the WMP plugin work in order to "make sites [like gamespot] work". The complaint that "too many sites don't work" is still hurled at Mozilla and Netscape by PC vendors, when justifying their decisions not to bundle a Mozilla browser alongside IE, just as an alternative.
Physician, heal thyself. I give specific reasons for not bowing to arguments from authority. You whine factlessly about my rejection of your favorite authority. Who is being arrogant here?
Just because the w3c endorses a specification does not mean that spec is a good or necessary standard (which, sorry to disappoint you, I and many others who agree with my point of view do believe exist).
The w3c uses a closed, multi-year process where too many big and small companies pay-to-play and design-by-committee, with too little backward compatibility, and not even consistency among their own specs (e.g., the CSS and DOM deviations in SVG). Specs go to REC status without complete implementation or widespread market testing.
The consequent neglect of HTML, DOM level 0, and other under- or un-specified de-facto standards used by billions of web pages, has aided and abetted MS in cementing its monopoly. And now that monopoly vendor is moving the goal posts on the entire web client game. I do not whine about this (unlike you, who seems content to whine in/. about bad ol' me) -- I'm actually working on ways to combat web monoculture. This focus is about to curtail my time responding on/., but feel free to mail me.
If your idea of fighting the bad effects of IE or Windows Longhorn on the web is "implement XForms in Mozilla", then you need to calm down and explain how that does anything except waste time and bloat Gecko's footprint. Without any browser market share to speak of, even if Mozilla supported XForms, web content authors in a few years are much likelier to use XAML than XForms. Apple, Opera, and IE will never support XForms natively, and XForms plugins are neither well-distributed not transparently integrated with HTML and other supported standards.
So give it a rest -- try fact-based opinions instead of w3c authority trips for a change.
If your "I want a standards compliant browser" demand means anything here, it can only mean that this is all about *you* and *your wants*. "Uncompromising" standards compliance is a goal of Mozilla for standards that actually matter in the real world, like HTML, CSS, and DOM (including the unspecified parts). If on your planet, XForms matters, get busy implementing it in Mozilla. We're accepting patches.
Good point about Apple, but only half the truth is told here. Apple is not targeting commodity PC hardware. It has its own boutique hardware that people want in addition to the boutique software Apple purveys. This is a huge advantage, although of limited growth potential, and an advantage that is not transferable to Linux.
Embedding is hardly a growth market. There are at most a handful of apps that might embed Gecko on Linux, and Mozilla would get little or no funding or user-agent market share from them. The embedding apps would free-ride on the funding from AOL, and on recurring funding from strategic partners that the Mozilla Foundation has gained through application-based strategies since its founding.
Consider that PTC, maker of ProEngineer, has been embedding Gecko for years in ProE on Linux (on Windows, ProE uses Trident). Good for PTC, we support their embedding -- but it has not benefited Mozilla with either funding or measurable user-agent market share.
This may be heresy to open-source true believers, but maintaining and extending Gecko requires a minimum number of paid, full-time hackers, managers, and QA and release staff, in addition to the wide and deep volunteer community from which those staff were hired. Currently Sun, IBM, Red Hat, and the Mozilla Foundation, at least, employ such people. The need for paid staff comes from the complexity of the web: 5 billion public pages, millions of private intranet pages and web apps, lots of quirks and buggy content, de-facto standards, gaps in de-jure standards.
To fund an effort of this scale, you need a successful business strategy.
You propose a "killer embedded library" strategy, which would be a departure from what works. Let's look at three strategies already in use in Mozilla's area, Internet client software:
Mozilla already has "killer app" strategies in place funding the browser and, more recently, Thunderbird.
MS's "killer apps on OS monopoly" ping-pong strategy is well known. MS also has "killer tools for programmers" and "extensive developer support/documentation" efforts that undergird a "developer mindshare" strategy that builds on and perpetuates the OS monopoly, and that may yield killer apps (which MS then can acquire).
Macromedia made the right moves early with Flash, building great tools and gaining >90% distribution of the FlashPlayer plugin, and they're parlaying that into a "killer rich client app platform" strategy. Good for them, but Mozilla lacks that well-distributed a front end, and lacks the tools (and the need for tools -- the web was and probably will continue to be mostly built by hand).
The striking thing about these examples is the emphasis on end-user or developer applications that make real revenue. No one is just purveying anything like a web content engine library to be embedded in unknown applications, and getting any kind of return on investment. This is not surprising. There is no commerically viable "killer embedded library" business for web content engines, thanks to MS subsidizing Trident to zero cost on Windows, and Apple doing the same for KHTML on Mac OS X.
(Yes, MS and even Apple, for all I know, have tried and are trying to recoup some of the huge costs they've sunk, by for example charging AOL or Intuit for the privilege of embedding a supported version of Trident, or licensing its source. But that does not make a viable business out of the subsidies.)
Those subsidies also made browsers free on those OSes, but browsers are still killer apps, mainly because they are sufficient front ends to web apps, which have displaced fat/proprietary/vertical client/server apps.
There are still people, not all end-users, who will pay for browsers, and not only on Linux. Some customers don't want to be locked into the OS vendor's browser, especially when it is IE. Some customers value cross-platform reach, for migration and coverage. "Customer" here includes anyone helping fund the engine and the killer app that uses it
Good point about Apple, but only half the truth is told here. Apple is not targeting commodity PC hardware. It has its own boutique hardware that people want in addition to the boutique software Apple purveys. This is a huge advantage, although of limited growth potential, and an advantage that is not transferable to Linux.
Embedding is hardly a growth market. There are at most a handful of apps that might embed Gecko on Linux, and Mozilla would get little or no funding or user-agent market share from them. The embedding apps would free-ride on the funding from AOL, and on recurring funding from strategic partners that the Mozilla Foundation has gained through application-based strategies since its founding.
Consider that PTC, maker of ProEngineer, has been embedding Gecko for years in ProE on Linux (on Windows, ProE uses Trident). Good for PTC, we support their embedding -- but it has not benefited Mozilla with either funding or measurable user-agent market share.
This may be heresy to open-source true believers, but maintaining and extending Gecko requires a minimum number of paid, full-time hackers, managers, and QA and release staff, in addition to the wide and deep volunteer community from which those staff were hired. Currently Sun, IBM, Red Hat, and the Mozilla Foundation, at least, employ such people. The need for paid staff comes from the complexity of the web: 5 billion public pages, millions of private intranet pages and web apps, lots of quirks and buggy content, de-facto standards, gaps in de-jure standards.
To fund an effort of this scale, you need a successful business strategy.
You propose a "killer embedded library" strategy, which would be a departure from what works. Let's look at three strategies already in use in Mozilla's area, Internet client software:
Mozilla already has "killer app" strategies in place funding the browser and, more recently, Thunderbird.
MS's "killer apps on OS monopoly" ping-pong strategy is well known. MS also has "killer tools for programmers" and "extensive developer support/documentation" efforts that undergird a "developer mindshare" strategy that builds on and perpetuates the OS monopoly, and that may yield killer apps (which MS then can acquire).
Macromedia made the right moves early with Flash, building great tools and gaining >90% distribution of the FlashPlayer plugin, and they're parlaying that into a "killer rich client app platform" strategy. Good for them, but Mozilla lacks that well-distributed a front end, and lacks the tools (and the need for tools -- the web was and probably will continue to be mostly built by hand).
The striking thing about these examples is the emphasis on end-user or developer applications that make real revenue. No one is just purveying anything like a web content engine library to be embedded in unknown applications, and getting any kind of return on investment. This is not surprising. There is no commerically viable "killer embedded library" business for web content engines, thanks to MS subsidizing Trident to zero cost on Windows, and Apple doing the same for KHTML on Mac OS X.
(Yes, MS and even Apple, for all I know, have tried and are trying to recoup some of the huge costs they've sunk, by for example charging AOL or Intuit for the privilege of embedding a supported version of Trident, or licensing its source. But that does not make a viable business out of the subsidies.)
Those subsidies also made browsers free on those OSes, but browsers are still killer apps, mainly because they are sufficient front ends to web apps, which have displaced fat/proprietary/vertical client/server apps.
There are still people, not all end-users, who will pay for browsers, and not only on Linux. Some customers don't want to be locked into the OS vendor's browser, especially when it is IE. Some customers value cross-platform reach, for migration and coverage. "Customer" here includes anyone helping fund the engine and the killer app that uses it widely. This includes service outfits such as web portals, who
I'm not sure what is meant by "Customers want modal dialog boxes. Try making anything modal in Mozilla." How about a bugzilla reference?
Clearly, Mozilla can do modal dialogs (e.g., for JavaScript DOM level 0 window.alert,.confirm, and.prompt methods), and has been able to for a long time. Have a read at http://lxr.mozilla.org/mozilla/search?string=CHROM E_MODAL and please file any bugs you find with existing modal dialog support./be
That quote from staff minutes was out of context. I was citing the agreement I'd reached with all-volunteer Mozilla Firebird developers before the Mozilla Foundation was announced, where 0.7 would coincide with 1.5, 0.8 with 1.6, etc. I went on to say to staff, at that meeting, that if we get more time from the developers, the schedule could be shortened.
Now, we hope to hire a Firebird developer fulltime at the Mozilla Foundation, and we expect to go faster. No promises yet; the roadmap will be updated in due course.
You're right about KHTML being the better open source alternative for Apple. I would have made the same decision, were I in the Safari team's shoes a year ago, operating under the constraint of secrecy, having to hire a team who didn't know either KHTML or Gecko, and had to learn one or the other from scratch.
(Of course, I wouldn't want to work under those constraints, if I had the choice.)
I apologize if I misread the original post. Lately there has been a lot of "Apple picked KHTML, so Gecko must be deficient in all situations" talk -- but we agree that's fallacious.
Your second point misconstrues mine about Apple being prepared to carry its tine of a fork. My point is that Apple management wanted to develop in secret, which decision inherently risks a fork.
Netscape has not done that. Almost all of its MPL'ed changes, certainly all to the core Gecko code (not necessarily all of UI changes under xpfe -- but most of those, too) go into cvs.mozilla.org early and often. They don't hide behind a firewall in a commercial source tree for a year, while the open source they're based on diverges.
MPL vs. LGPL had nothing to do with the point I was making. Anyone willing to publish diffs or distribute them along with programs can perpetrate a fork of code provided under either license.
I use the integrated suite every day -- mostly the browser, mail/news, and message compose. Before any change to the default build, we'll make sure that this mode of operation is possible if you configure mail (Thunderbird, I mean) as an add-on to the Phoenix-based browser.
Remember, your add-ons persist across upgrades, unless an incompatible change to the new toolkit (which is XUL, XBL, JS, and CSS) invalidates a particular add-on (in which case, you'll need to get the new, compatible version of that add-on once it's out; this kind of invalidation should not happen often). So once you've added the mail extension to the browser, you're set -- you should be able to operate just as you do today with the integrated app-suite.
That's the goal, anyway, and a requirement to meet before we switch the default build.
Longer answer: we brought XUL up because if we "switch to Phoenix" from the app-suite browser, based on Phoenix as it has been distributed so far, we drop Mac XUL support. We don't want to do that. So in the roadmap, we go out of our way to say that we *are* going to build Phoenix for OS X, when we switch.
I wonder how we can make this simple point more clear, without inviting confusion. Jumpy roadmap readers seem to skim, and fly off the handle out of fear that we're dropping XUL, or something silly like that. Rest assured, we are supporting XUL fully.
XUL with some form-submission smarts, but using XML-RPC, SOAP, WSDL, or whatever's appropriate, should become the basis for web applications. XUL widgets should form the kernel of a pragmatic XForms implementation. And XUL's still great for cross-platform applications. We like XUL too.
KHTML was a smaller codebase than Gecko, and easier for a new project to make completely their own. That's right, there was a better open source alternative out there most people had never really thought about.
Why in the world does either "smaller codebase", or "easier for a new project [at Apple, working stealthily] to make completely their own", define "better open source alternative"?
The second claim, "easier for a new stealth project to make their own", is arguably bad for open source, although it looks like Apple has worked out arrangements to give back its changes without too much pain (a KJS2 fork, a few big merges). All's well in the end, but Apple took chances with forks, and from what I can tell was prepared to carry its own tine of the fork, forever. Apple chose KHTML because it was easier to own, if necessary, than Gecko -- that's true. But that fact doesn't make KHTML the better open source anything.
As for the first claim: "smaller" is better until you want in-page editing of arbitrary block level elements (contentEditable, available in Mozilla now), or good XML support, or XSLT, or MathML, or SVG, or a bunch of web compatibility bugfixing that Safari has yet to do. Then, even though KHTML is a fine engine, you might prefer, given all the trade-offs, to use Gecko.
These black-white, good-bad disjunctions between large, not-quite-competing software systems are unreal. Complex software comes with a set of complex trade-offs. On someone's absolute scale of goodness, KHTML may be "better" than Gecko. Heck, I could agree to that, based mainly on size of codebase (source and compiled), or on aesthetics (I prefer lean C++ to stylized, design-patterns-infected, not-quite-COM object-oriented hoohah).
But in the real world, you have to state requirements carefully and trade off costs and benefits with relative judgments. Gecko does not always lose to KHTML, for all scenarios where you need something like an embedded layout engine (See ptc.com for one embedded Gecko example).
And the reason Apple chose KHTML does not matter a bit to other entities looking for such an engine. Nor does that reason decide which engine is the better open source alternative in general.
All large, mature codebases are messy -- that's a true fact of life in the real software world. Maybe they don't teach that in school yet. They should.
Gecko is less messy than the old, MozillaClassic codebase. It's still messy -- it must be so, remember, because it is real. Plus, many hands have handled it. Also, it was over-designed a bit, or a lot, in places -- but that's water under the bridge.
Gecko does a *lot*, way more than the old codebase. HTML4, CSS1, CSS2.1, parts of CSS3, DOM levels 1-3, XML, XSL-T, SVG, MathML, SOAP, WSDL,.... Hacking all that on top of the old codebase cleanly could be done, but it would have taken a ton of effort -- assuming we could've found anyone interested in doing the work.
True statement: the reason we ditched the "Netscape 5" code was not because it was messy. The reason was that we simply could not interest enough new people, inside or outside of Netscape, in learning to deal with the mess, and then clean it up, and furthermore build on top of it. Almost all of the "old people" who wrote that codebase had moved on to other things.
Someone please mention this overriding non-technical fact to http://joelonsoftware.com. Joel may be right to call all the newcomers who were unwilling to work on the old codebase "undisciplined" or "unprofessional" -- if those words are fair, then all I can say is that there are not many disciplined professionals in software to be found. I worked on both codebases extensively (I created the DOM "level 0" along with JavaScript in 1995, for Nav2), but I can't claim to be either disciplined or professional.
Meanwhile, during 1998, Netscape had a team working on the "NGLayout" project, and they wanted to contribute that new layout engine. We (mozilla.org) took a chance, preferring the new frontiers of that codebase to the crowded, overdeveloped old world. The lure of the frontier, the chance to homestead your own plot, especially using XML and JS, was what mozilla.org needed most in order to attract contributors. People simply could not sink the costs required to learn the old C/C++ codebase enough to scratch their itches.
Our gamble worked, I think. Not without many bumps along the way (and whose idea was shipping Netscape 6, anyway? Not mine!). Now, our top Gecko hackers are people such as dbaron@dbaron.org, who has recently graduated from Harvard, and who is an invited expert on the W3C CSS working group; rbs@maths.uq.edu.au; and bzbarsky@mit.edu.
Yeah, it took too long. There are no shortcuts. We should have done better. But doing "just a browser" was never in the cards, and not only because of Netscape's commitments. Mozilla is and always will be more than "just a browser". As jwz wrote here a while ago, if you want just a browser, stop whining and go use Konqueror, Galeon, K-Meleon, or any of a number of choices, depending on your preferred platform. (Don't kid yourself that Mozilla could have stopped IE's distribution-channel-based takeover, no matter what we did.)
If you want to help Mozilla, please come join us. With the new roadmap, we have more new frontier land to develop.
Slashdot Mirror
What everyone wants, what even Microsoft is "reacting" to, is the graphics capabilities of modern PCs, the ease of UI and graphical design inherent in XML declarations and managed code driving a layout and rendering engine, and the current failure of web standards to marry the two. MS can cut through the red tape and make a UI and graphics language that rivals XUL and Macromedia's Flex markup language combined.
Matching MS's every move is stupid, and it wasn't what anyone proposed. Building a competitive graphics and UI toolkit together was on the table, because otherwise the open source alternative to things like XAML (or MXML) is fragmented and weak.
BTW, Active X plugins are supported in Mozilla, conditionally (whitelist empty by default). Too many sites use Windows Media Player, and it requires Active X plugin glue. Last I heard, http://www.gamespot.com/ still showed hot new games' cut-scenes using WMP only.
You should know that mozilla.org does not endorse Active X, but Netscape/AOL funded the WMP plugin work in order to "make sites [like gamespot] work". The complaint that "too many sites don't work" is still hurled at Mozilla and Netscape by PC vendors, when justifying their decisions not to bundle a Mozilla browser alongside IE, just as an alternative.
Just because the w3c endorses a specification does not mean that spec is a good or necessary standard (which, sorry to disappoint you, I and many others who agree with my point of view do believe exist).
The w3c uses a closed, multi-year process where too many big and small companies pay-to-play and design-by-committee, with too little backward compatibility, and not even consistency among their own specs (e.g., the CSS and DOM deviations in SVG). Specs go to REC status without complete implementation or widespread market testing.
The consequent neglect of HTML, DOM level 0, and other under- or un-specified de-facto standards used by billions of web pages, has aided and abetted MS in cementing its monopoly. And now that monopoly vendor is moving the goal posts on the entire web client game. I do not whine about this (unlike you, who seems content to whine in /. about bad ol' me) -- I'm actually working on ways to combat web monoculture. This focus is about to curtail my time responding on /., but feel free to mail me.
If your idea of fighting the bad effects of IE or Windows Longhorn on the web is "implement XForms in Mozilla", then you need to calm down and explain how that does anything except waste time and bloat Gecko's footprint. Without any browser market share to speak of, even if Mozilla supported XForms, web content authors in a few years are much likelier to use XAML than XForms. Apple, Opera, and IE will never support XForms natively, and XForms plugins are neither well-distributed not transparently integrated with HTML and other supported standards.
So give it a rest -- try fact-based opinions instead of w3c authority trips for a change.
If your "I want a standards compliant browser" demand means anything here, it can only mean that this is all about *you* and *your wants*. "Uncompromising" standards compliance is a goal of Mozilla for standards that actually matter in the real world, like HTML, CSS, and DOM (including the unspecified parts). If on your planet, XForms matters, get busy implementing it in Mozilla. We're accepting patches.
Embedding is hardly a growth market. There are at most a handful of apps that might embed Gecko on Linux, and Mozilla would get little or no funding or user-agent market share from them. The embedding apps would free-ride on the funding from AOL, and on recurring funding from strategic partners that the Mozilla Foundation has gained through application-based strategies since its founding.
Consider that PTC, maker of ProEngineer, has been embedding Gecko for years in ProE on Linux (on Windows, ProE uses Trident). Good for PTC, we support their embedding -- but it has not benefited Mozilla with either funding or measurable user-agent market share.
This may be heresy to open-source true believers, but maintaining and extending Gecko requires a minimum number of paid, full-time hackers, managers, and QA and release staff, in addition to the wide and deep volunteer community from which those staff were hired. Currently Sun, IBM, Red Hat, and the Mozilla Foundation, at least, employ such people. The need for paid staff comes from the complexity of the web: 5 billion public pages, millions of private intranet pages and web apps, lots of quirks and buggy content, de-facto standards, gaps in de-jure standards.
To fund an effort of this scale, you need a successful business strategy.
You propose a "killer embedded library" strategy, which would be a departure from what works. Let's look at three strategies already in use in Mozilla's area, Internet client software:
Mozilla already has "killer app" strategies in place funding the browser and, more recently, Thunderbird.
MS's "killer apps on OS monopoly" ping-pong strategy is well known. MS also has "killer tools for programmers" and "extensive developer support/documentation" efforts that undergird a "developer mindshare" strategy that builds on and perpetuates the OS monopoly, and that may yield killer apps (which MS then can acquire).
Macromedia made the right moves early with Flash, building great tools and gaining >90% distribution of the FlashPlayer plugin, and they're parlaying that into a "killer rich client app platform" strategy. Good for them, but Mozilla lacks that well-distributed a front end, and lacks the tools (and the need for tools -- the web was and probably will continue to be mostly built by hand).
The striking thing about these examples is the emphasis on end-user or developer applications that make real revenue. No one is just purveying anything like a web content engine library to be embedded in unknown applications, and getting any kind of return on investment. This is not surprising. There is no commerically viable "killer embedded library" business for web content engines, thanks to MS subsidizing Trident to zero cost on Windows, and Apple doing the same for KHTML on Mac OS X.
(Yes, MS and even Apple, for all I know, have tried and are trying to recoup some of the huge costs they've sunk, by for example charging AOL or Intuit for the privilege of embedding a supported version of Trident, or licensing its source. But that does not make a viable business out of the subsidies.)
Those subsidies also made browsers free on those OSes, but browsers are still killer apps, mainly because they are sufficient front ends to web apps, which have displaced fat/proprietary/vertical client/server apps.
There are still people, not all end-users, who will pay for browsers, and not only on Linux. Some customers don't want to be locked into the OS vendor's browser, especially when it is IE. Some customers value cross-platform reach, for migration and coverage. "Customer" here includes anyone helping fund the engine and the killer app that uses it
Mozilla already has "killer app" strategies in place funding the browser and, more recently, Thunderbird.
MS's "killer apps on OS monopoly" ping-pong strategy is well known. MS also has "killer tools for programmers" and "extensive developer support/documentation" efforts that undergird a "developer mindshare" strategy that builds on and perpetuates the OS monopoly, and that may yield killer apps (which MS then can acquire).
Macromedia made the right moves early with Flash, building great tools and gaining >90% distribution of the FlashPlayer plugin, and they're parlaying that into a "killer rich client app platform" strategy. Good for them, but Mozilla lacks that well-distributed a front end, and lacks the tools (and the need for tools -- the web was and probably will continue to be mostly built by hand). The striking thing about these examples is the emphasis on end-user or developer applications that make real revenue. No one is just purveying anything like a web content engine library to be embedded in unknown applications, and getting any kind of return on investment. This is not surprising. There is no commerically viable "killer embedded library" business for web content engines, thanks to MS subsidizing Trident to zero cost on Windows, and Apple doing the same for KHTML on Mac OS X. (Yes, MS and even Apple, for all I know, have tried and are trying to recoup some of the huge costs they've sunk, by for example charging AOL or Intuit for the privilege of embedding a supported version of Trident, or licensing its source. But that does not make a viable business out of the subsidies.) Those subsidies also made browsers free on those OSes, but browsers are still killer apps, mainly because they are sufficient front ends to web apps, which have displaced fat/proprietary/vertical client/server apps. There are still people, not all end-users, who will pay for browsers, and not only on Linux. Some customers don't want to be locked into the OS vendor's browser, especially when it is IE. Some customers value cross-platform reach, for migration and coverage. "Customer" here includes anyone helping fund the engine and the killer app that uses it widely. This includes service outfits such as web portals, who
Clearly, Mozilla can do modal dialogs (e.g., for JavaScript DOM level 0 window.alert, .confirm, and .prompt methods), and has been able to for a long time. Have a read at http://lxr.mozilla.org/mozilla/search?string=CHROM E_MODAL and please file any bugs you find with existing modal dialog support. /be
That quote from staff minutes was out of context. I was citing the agreement I'd reached with all-volunteer Mozilla Firebird developers before the Mozilla Foundation was announced, where 0.7 would coincide with 1.5, 0.8 with 1.6, etc. I went on to say to staff, at that meeting, that if we get more time from the developers, the schedule could be shortened.
Now, we hope to hire a Firebird developer fulltime at the Mozilla Foundation, and we expect to go faster. No promises yet; the roadmap will be updated in due course.
You're right about KHTML being the better open source alternative for Apple. I would have made the same decision, were I in the Safari team's shoes a year ago, operating under the constraint of secrecy, having to hire a team who didn't know either KHTML or Gecko, and had to learn one or the other from scratch.
(Of course, I wouldn't want to work under those constraints, if I had the choice.)
I apologize if I misread the original post. Lately there has been a lot of "Apple picked KHTML, so Gecko must be deficient in all situations" talk -- but we agree that's fallacious.
Your second point misconstrues mine about Apple being prepared to carry its tine of a fork. My point is that Apple management wanted to develop in secret, which decision inherently risks a fork.
Netscape has not done that. Almost all of its MPL'ed changes, certainly all to the core Gecko code (not necessarily all of UI changes under xpfe -- but most of those, too) go into cvs.mozilla.org early and often. They don't hide behind a firewall in a commercial source tree for a year, while the open source they're based on diverges.
MPL vs. LGPL had nothing to do with the point I was making. Anyone willing to publish diffs or distribute them along with programs can perpetrate a fork of code provided under either license.
I use the integrated suite every day -- mostly the browser, mail/news, and message compose. Before any change to the default build, we'll make sure that this mode of operation is possible if you configure mail (Thunderbird, I mean) as an add-on to the Phoenix-based browser.
Remember, your add-ons persist across upgrades, unless an incompatible change to the new toolkit (which is XUL, XBL, JS, and CSS) invalidates a particular add-on (in which case, you'll need to get the new, compatible version of that add-on once it's out; this kind of invalidation should not happen often). So once you've added the mail extension to the browser, you're set -- you should be able to operate just as you do today with the integrated app-suite.
That's the goal, anyway, and a requirement to meet before we switch the default build.
"what exactly is happening to XUL?"
Short answer: nothing; sorry we mentioned it.
Longer answer: we brought XUL up because if we "switch to Phoenix" from the app-suite browser, based on Phoenix as it has been distributed so far, we drop Mac XUL support. We don't want to do that. So in the roadmap, we go out of our way to say that we *are* going to build Phoenix for OS X, when we switch.
I wonder how we can make this simple point more clear, without inviting confusion. Jumpy roadmap readers seem to skim, and fly off the handle out of fear that we're dropping XUL, or something silly like that. Rest assured, we are supporting XUL fully.
XUL with some form-submission smarts, but using XML-RPC, SOAP, WSDL, or whatever's appropriate, should become the basis for web applications. XUL widgets should form the kernel of a pragmatic XForms implementation. And XUL's still great for cross-platform applications. We like XUL too.
Why in the world does either "smaller codebase", or "easier for a new project [at Apple, working stealthily] to make completely their own", define "better open source alternative"?
The second claim, "easier for a new stealth project to make their own", is arguably bad for open source, although it looks like Apple has worked out arrangements to give back its changes without too much pain (a KJS2 fork, a few big merges). All's well in the end, but Apple took chances with forks, and from what I can tell was prepared to carry its own tine of the fork, forever. Apple chose KHTML because it was easier to own, if necessary, than Gecko -- that's true. But that fact doesn't make KHTML the better open source anything.
As for the first claim: "smaller" is better until you want in-page editing of arbitrary block level elements (contentEditable, available in Mozilla now), or good XML support, or XSLT, or MathML, or SVG, or a bunch of web compatibility bugfixing that Safari has yet to do. Then, even though KHTML is a fine engine, you might prefer, given all the trade-offs, to use Gecko.
These black-white, good-bad disjunctions between large, not-quite-competing software systems are unreal. Complex software comes with a set of complex trade-offs. On someone's absolute scale of goodness, KHTML may be "better" than Gecko. Heck, I could agree to that, based mainly on size of codebase (source and compiled), or on aesthetics (I prefer lean C++ to stylized, design-patterns-infected, not-quite-COM object-oriented hoohah).
But in the real world, you have to state requirements carefully and trade off costs and benefits with relative judgments. Gecko does not always lose to KHTML, for all scenarios where you need something like an embedded layout engine (See ptc.com for one embedded Gecko example).
And the reason Apple chose KHTML does not matter a bit to other entities looking for such an engine. Nor does that reason decide which engine is the better open source alternative in general.
All large, mature codebases are messy -- that's a true fact of life in the real software world. Maybe they don't teach that in school yet. They should.
.... Hacking all that on top of the old codebase cleanly could be done, but it would have taken a ton of effort -- assuming we could've found anyone interested in doing the work.
Gecko is less messy than the old, MozillaClassic codebase. It's still messy -- it must be so, remember, because it is real. Plus, many hands have handled it. Also, it was over-designed a bit, or a lot, in places -- but that's water under the bridge.
Gecko does a *lot*, way more than the old codebase. HTML4, CSS1, CSS2.1, parts of CSS3, DOM levels 1-3, XML, XSL-T, SVG, MathML, SOAP, WSDL,
True statement: the reason we ditched the "Netscape 5" code was not because it was messy. The reason was that we simply could not interest enough new people, inside or outside of Netscape, in learning to deal with the mess, and then clean it up, and furthermore build on top of it. Almost all of the "old people" who wrote that codebase had moved on to other things.
Someone please mention this overriding non-technical fact to http://joelonsoftware.com. Joel may be right to call all the newcomers who were unwilling to work on the old codebase "undisciplined" or "unprofessional" -- if those words are fair, then all I can say is that there are not many disciplined professionals in software to be found. I worked on both codebases extensively (I created the DOM "level 0" along with JavaScript in 1995, for Nav2), but I can't claim to be either disciplined or professional.
Meanwhile, during 1998, Netscape had a team working on the "NGLayout" project, and they wanted to contribute that new layout engine. We (mozilla.org) took a chance, preferring the new frontiers of that codebase to the crowded, overdeveloped old world. The lure of the frontier, the chance to homestead your own plot, especially using XML and JS, was what mozilla.org needed most in order to attract contributors. People simply could not sink the costs required to learn the old C/C++ codebase enough to scratch their itches.
Our gamble worked, I think. Not without many bumps along the way (and whose idea was shipping Netscape 6, anyway? Not mine!). Now, our top Gecko hackers are people such as dbaron@dbaron.org, who has recently graduated from Harvard, and who is an invited expert on the W3C CSS working group; rbs@maths.uq.edu.au; and bzbarsky@mit.edu.
Yeah, it took too long. There are no shortcuts. We should have done better. But doing "just a browser" was never in the cards, and not only because of Netscape's commitments. Mozilla is and always will be more than "just a browser". As jwz wrote here a while ago, if you want just a browser, stop whining and go use Konqueror, Galeon, K-Meleon, or any of a number of choices, depending on your preferred platform. (Don't kid yourself that Mozilla could have stopped IE's distribution-channel-based takeover, no matter what we did.)
If you want to help Mozilla, please come join us. With the new roadmap, we have more new frontier land to develop.