Can’t find it now, but I read somewhere that the next Ubiquity release are to use Jetpack as a back-end.

It probably was this, but Aza’s post is gone (still available on planet though)

When the Jetpack SDK hits 1.0, we plan on moving Ubiquity to the new platform and start working on the next iteration building on the learnings from the nearly half a million people who have downloaded Ubiquity. For now, however except only a maintenance release to make 0.5 work with Fx 3.6

I’m not too clear on what Haiku is, but I’d guess they also wanted the whole support for HTML/XML bit that came with WebKit, not just the JavaScript engine, without the support for XUL, extensions, et al that comes with XULRunner and thus chose WebKit in the end.

There are “packets” available for the Java JavaScript client, Rhino. But for the C version it seems like you’ll have to checkout the source using Hg? There are sources available for both the latest, mozilla central, and for the Firefox 3.6 branch, mozilla 1.9.2.

but reading that Ubiquity was put on hold to finish up other projects is a sign of under staffing in my book

Can’t find it now, but I read somewhere that the next Ubiquity release are to use Jetpack as a back-end. Also, much of the work that went into Ubiquity were used as a base for Jetpack.

Oh, and I never talked about ACID3, as it is mostly marketing hype what is left out (for now?) from Gecko, as RoC explained well.

About ACID3
A semi-related comment by Alex Faaborg on the default placement of the tab-bar, a minor issue, in my opinion, that is perceived as important by the general user-base much like the last points on ACID3.

There is a general perception that placing tabs in a more conceptually pure
configuration is “modern and sleek” while the traditional placement is “old and
clunky.” This is purely an emotional design and brand level consideration,
primarily caused by Chrome being the “new” product in the marketplace, and
Firefox presently being the “old” product in the marketplace. Had we made the
change with Firefox 3 on Vista, we would not currently be facing this
situation. However we are now at a state where deploying the more conceptually
pure design is “copying” or “catching up,” and failing to deploy it may be
interpreted as “stagnating” or “falling behind.” The product perception issues
related to tab placement appear to be a lose/lose at this point.

But it’s not an either/or. It’s not like we could grow the engineering team any faster if we didn’t hire marketing people.

Success at Mozilla’s mission of keeping the web open requires Firefox market share. Without that, we are irrelevant. And a way to grow market share is to make sure people know about Firefox. We’ve got an amazing community who do a great deal, and (as I’ve said) we have far fewer marketers than most companies with 350 million customers.

Are you saying we shouldn’t do marketing at all? Or that all our marketers should be volunteers?

“If XUL Runner isn’t an important goal (IMHO spreading the platform is always good, since more people use your code and find bugs or improve it), just say so; that’s fine.”

My understanding is that it’s been said several times over the past few years. But don’t take XULRunner policy from me; get it from someone like bsmedberg.

You seem to be saying we should only add technologies if we know they are going to be successful. In other words, we shouldn’t make mistakes. Can I borrow your crystal ball, then? It would be very useful… But seriously, that’s why we now have Labs – so we can do experiments and see what works and what people like. Personas was a successful experiment. Snowl was interesting but didn’t go very far. Ubiquity, we haven’t quite cracked yet – the jury’s still out.

Gerv

On the last part of your post, I’ll try to explain me differently with an example.
Long ago, someone came out with the bright idea of using some sort of db engine to manage bookmarks, history, etc. So sqlite was added, Places was born and the Awesome Bar was developed. This is what I mean with leveraging on your own technologies: adding features that allow real innovation, impacting all FF users. All was done with a goal and a direction in mind, planning most of it, right?

I’ll give a counter-example of a technology added to Mozilla which was of no use: P3P, and we all know how it ended. Adding “n” features for the sake of it is just feature creep, which leads to bloat, not to innovation.

I have to repeat myself once more (sorry, but this will be the last time):

this is not a flame, just a funny note

There is none so deaf as he who will not hear…

Yes, I think he said something like that. But it turned out that we have very smart people who can do hard things. And I’m sure looking at Chrome’s design helped.

And bear in mind we are a distance from having it working completely and shippable, even now. We’ve been focussed on the more limited goal of out-of-process plugins. Getting that total separation is a lot more work.

“I was simply expressing my fears that marketing is being used to cover up technological gaps FF has collected through the years”

You would prefer that our marketing department concentrated on telling people about our weaknesses?

“3 different Mozilla employees have used the example of the 2 groups of smart people coming to the same conclusions…”

I have not consulted anyone else in writing my responses to your blog post; there is no “company line” and no collusion.

Responding to your second post: in your view, why is doing XULRunner an important goal for the Mozilla project?

“But is Mozilla leveraging on those inside its own products or are they just adding items to the list of features the others don’t have?”

Hang on a minute… earlier you were complaining about the lack of innovation and differentiation. Now you are saying “what? are you just _innovating_? That’s not good enough…” It’s starting to look like you are working hard to find something to complain about.

Gerv