I’ve already received some encouraging feedback to my latest Mozpad post (I’ll be posting a followup soon). Further positive news is that I’ve made good, in a small way at least, on my pledge to devote some time to the Mozpad documentation project.
Having labored to get Prism to build using the Mozilla build system, I was struck by the lack of documentation on this topic for XULRunner developers in general. There’s a blog post by Songbird’s Ben Turner and there’s Dave Townsend’s McCoy project, which is a great practical example of how to do it. But nothing comprehensive on the documentation site.
So I decided to turn my original “Creating Custom Firefox Extensions with the Mozilla Build System” article into a franchise with “Creating XULRunner Apps with the Mozilla Build System”. The article has yet to be reviewed, and to quote Douglas Adams, “it has many omissions and contains much that is apocryphal, or at least wildly inaccurate.” (Unfortunately I didn’t think to adorn it with a prominent “Don’t Panic” label, although this would certainly have been apt.)
Stay tuned for new additions to the series, including “Traditional Chinese Calligraphy with the Mozilla Build System”, “Mastering the Mental Game of Golf with the Mozilla Build System” and the much-anticipated “12 Days to a Flatter Stomach with the Mozilla Build System”.
Mike Shaver asked me about Mozpad the other day, and a few hours later Brian King posed the same question on his blog. Clearly it’s high time to take a step back and evaluate where we are and where we’re going.
The short answer is that not much has happened on the Mozpad front recently. To some degree this is just a case of things taking time. There is definitely ongoing interest in a XULRunner IDE, and ActiveState has brought this a whole whack closer to reality with their Open Komodo initiative. But the initial excitement and momentum has largely dissipated.
I was musing months ago that the group lacked a clear raison d’être. The problem isn’t so much a dearth of things to do, but the commitment and time investment that would be necessary to do them right. This isn’t just a case of setting up some discussion forums for technical support (Mozilla already has them) or an IRC chat room (Mozilla has several) or a great, user-editable documentation site (cause, well, you get the point). Turning XULRunner into a real product with branding, packaging, development tools and marketing is perhaps too big a task for a volunteer organization without any full-time participants. Once folks realized how hard it was going to be to achieve anything substantive without jeopardizing their other projects (including the ones that pay the rent), their initial enthusiasm cooled. I can’t claim to be an exception in this regard.
There are other issues as well. First of all, where are all those XULRunner projects we’ve heard so much about? When we started Mozpad, I was expecting a lot of that XUL dark matter to come out of hiding and express interest in what we were up to. This simply didn’t happen. We got a lot of love from Mozilla die hards who find the idea of an open, multiplatform application development framework appealing, but virtually none from companies that are actually using the technology. It has to be said that Robert O’Callahan’s speculation about “hundreds or even thousands” of stealth XUL projects was based on rather scant evidence. Or perhaps the main interest is in developing intranet applications using a web server and XUL, rather than desktop apps on top of XULRunner. Or, equally plausibly, people are using XULRunner but weren’t aware of Mozpad or were waiting to see concrete results before making their interest known.
Moreover, I have to admit that I’ve cooled somewhat on the idea of XULRunner as a general purpose framework because I’m so excited about the potential of Prism. Since I believe rich web apps are the future, I’d rather spend whatever time I have for Mozilla platform work improving Prism rather than documenting XULRunner APIs and the like. And whereas Mozilla has stated unequivocally that a standalone XULRunner product is not a priority, Prism clearly is. I proposed Mozpad to a large degree because I felt that Mozilla had dropped the ball on the whole “future of apps” thing. Now I’ve got crow casserole heating in the oven as they pick up the ball and sprint for the goal line. (And with that let me pledge publicly: no more ball metaphors in 2007.)
(To be absolutely clear: none of this should be construed in any way as diminishing the heroic work that has been put into making XULRunner a viable platform and getting Firefox to run on top of libxul. Apart from anything else, Prism is a natural consequence of this extraordinary vision, which has been gestating for over three years.)
All this to say that a lot has changed since May, and I’m not sure that we need a Mozpad to further our goal of helping Mozilla to play a defining role in the future of applications. ActiveState has expressed interest in helping out with the development of a XULRunner IDE on top of Open Komodo. All the usual mechanisms are available for those who want to contribute ideas, bug reports and code to the Mozilla platform. Personally I’ve been spending a fair amount of time working on Prism. From my perspective, things are going great despite Mozpad’s lackluster second act.
Daniel Glazman has a followup post on the whole “Powered by Mozilla” thing (excellent initiative, did I mention?), which points to a droll and frustratingly anonymous rant on a new blog called “The Truth about Mozilla”.
I fell off my chair when I read that AllPeers is a “Mozpad front-company” and not just because of the incorrect hyphenation. (Save your cards, flowers and chocolates, I’m fine beyond a few psychological bumps and bruises.) That said, Mr. Anonymous does provide a reasonable if caustic counterpoint to Daniel’s and my contention that Mozilla platform developers would benefit if there were some way for them to leverage the better-known Firefox brand. (But what’s all this about Schrödinger’s cat? I’ve heard of mixing metaphors, but throwing in a physics thought experiment is a bold move. What good shit are you smoking, dude?)
Anyway, as my previous post on the topic implies, I disagree with the idea of trying to create a second trips-off-the-tongue brand out of Mozilla. Like I said, it’s hard enough to get traction with even one brand. As things stand, I must say “you know, the guys who make Firefox” about ten times a day.
And then there’s the general problem of what to call the platform. Mozilla, Gecko and XULRunner are often used interchangeably, and all of them have considerable drawbacks. Calling the platform “Firefox” is obviously problematic too, as Anonymous Mozilla Guy points out. But what about taking a feather out of BitTorrent’s cap? “Firefox DNA” is a bit me-too-ish. But something that uses the word “Firefox”, gets across the idea that “this is the stuff inside Firefox” while remaining clearly distinct from Firefox The Browser would be killer.
UPDATE: Before anyone else chastises me for “feeding the troll,” let me say in my defense that I didn’t read the earlier, more obnoxious posts on the “Truth about Mozilla” blog before linking to it. The post I link to seemed reasonable enough to me. I’d be on thin ice, after all, if I criticized his sarcastic tone and childish sense of humor (though I might plausibly demand royalties). Anyway, a lot of the posts do look like trolling, and the whole idea of a muck-raking Mozilla blog is silly, so please don’t patronize or link to his blog unless I explicitly say it’s okay.
UPDATE: Apparently it isn’t obvious that the bold portion of the previous update is tongue-in-cheek, at least if Cedric is any guide (a dubious premise, I admit). So lest it be too obtuse for some: I’m kidding!
I often talk to people who aren’t developers but still want to be able to contribute somehow to the open source world. If you have any kind of graphic design skills and want to support our effort to promote the Mozilla platform for developers, why not consider giving the Mozpad website a makeover? Let’s face it, considering the way it looks currently, it wouldn’t take much work to improve it.
Daniel Glazman comments on John Slater’s post about the excellent “Powered by Mozilla” initiative. I’ve seen this phenomenon directly or from a distance a number of times in my professional career. It’s hard to build a brand, and it’s doubly hard to build separate brands for a company and its flagship product.
In my experience, what inevitably happens is that the product garners much larger mind share, and the company eventually adopts its name in order to leverage its brand. Just thinking out loud, mind you…
Paul Rouget and Mariano Cuenze have been pushing forward the Mozpad IDE project, and we’re all jazzed up by the potential of Open Komodo to serve as the basis for an IDE for Mozilla developers. Shane Caraveo of ActiveState (makers of Komodo) has kindly offered to provide some guidance as to how we can best extend their product. Paul has written up some preliminary requirements in PDF and ODT formats. (I promised I would edit the text for grammar, but it actually looks fine to me for our current purposes.)
We’ll be meeting tomorrow at 4pm UTC in #mozpad. If anyone else is interested in talking about a Mozpad IDE built on Open Komodo, please feel free to join in the discussion.
I’ve updated the Mozpad API analysis page with additional statistics I received for Mozilla projects. I am planning to massage the results in various ways to provide additional views (e.g. sorted by frequency rather than interface). but this should tide us over in the meantime.
Many thanks to Nick Nassar of Miro, Wladimir Palant of TomTom, Javier Pedemonte of the AJAX Toolkit Framework, Pete Wilson of Mozdev and Matt Crocker of Songbird for providing data for their projects. I ended up biting the bullet and compiling the figures from the various files I received using Python, which meant (wait for it) I had to learn Python on Friday. This went surprisingly well due to a very supportive group of folks on IRC, notably Jason Orendorff, who has made a Python convert out of me in less than an hour.
It goes without saying that we’d love to feed more data into the stats. Please take a few minutes to run the script on your project and send me the results.
I’ve updated the API usage analysis for the AllPeers source tree as part of the Mozpad API project. The main update is that mozI* interfaces are now counted in addition to nsI* interfaces. The next step is to get other Mozilla-based projects to run the script and send me their results. I would really appreciate it if anyone reading this who is working on a large Mozilla project could run the script in their source tree root (make sure you don’t have other files like patches in the same tree that might pollute the statistics) and send me the results. Please specify if you want the data to be anonymous or if we can cite your project. I’m planning to nag people about this so why not be proactive? You’ll sleep more soundly, I promise.
While we gather the data, I’m planning to devote some time to the Mozpad documentation project.
When the iPhone was released, there was plenty of bellyaching about the lack of an SDK for third-party apps. Then Apple stepped up and announced that the “SDK” for the new device would be the Safari web browser, combined with Web 2.0 techniques (i.e. gobs of JavaScript on the client). Some hailed this as a visionary idea while others griped (somewhat paradoxically) that “web apps are not applications”. The situation became muddier when rogue developers quickly released a user interface toolkit and a package manager that makes it braindead simple to install native (albeit unauthorized) OS X apps designed for the iPhone.
I’ve been plugging the idea of web apps as the future of applications for a while, with a particular emphasis on WebRunner. So naturally I’ve been intrigued by Apple’s decision to make the web their official SDK. Having got my hot little hands on one, however, I’m disappointed by the current lack of features that would make this direction viable. As far as I can see, you can’t even add an app to the pretty grid of colorful icons that serves as the iPhone’s main menu. Besides integration with the underlying OS, there are many other gaps if the browser is to serve as an application platform: offline storage, Flash, more sophisticated web forms, etc. (Mike Shaver had a great overview of future web browser features at Mozilla 24.)
When Apple announced Safari for Windows I hypothesized that this would allow them to roll out exactly these kinds of proprietary browser-as-a-platform features. I still think that the use of web apps as the standard iPhone development paradigm is brilliant, but the current offering is totally inadequate. I predict that Apple will start to announce fancy new features for Safari or (hopefully) jump on board of existing efforts like XUL, Flex, Google Gears and the like.
The good folks from the Media in Transition conference have put the video of my presentation online. The title of the talk was “Building Media Distribution Apps”, touching on the trade-offs between various distribution techniques (e.g. streaming vs. downloads) and the new generation of rich internet application platforms (including XULRunner and WebRunner).
There is also a short video of an interview I gave after the talk.
UPDATE: I should have mentioned that the slides that go with the presentation can be found here.
There’s been some discussion on mozilla.dev.platform about whether that newsgroup should be used for newbie questions and other platform user support issues. Some platform developers are understandably concerned that this type of traffic will obscure internal communication.
We set up Mozpad exactly for application developers using the Mozilla platform, and we have a newsgroup (mozilla.community.mozpad) which could be used for this purpose. Personally I’d be thrilled to see this happen since it would be a significant contribution to the community. The main issue is that there aren’t nearly as many people subscribed to m.c.mozpad (I’m guessing) so the chance of getting an intelligent answer is not as high.
Gavin Sharp suggested to me that mozilla.development.extensions would be the right place for questions about using the platform. Gavin’s proposal is certainly sensible, particularly since it apparently corresponds to the status quo. But I still think that the “extensions” name is potentially confusing to newcomers, that the target audiences don’t overlap completely and that there would be value in a group specifically devoted to users of XULRunner and WebRunner.
Whatever the case might be, don’t hesitate to point people to m.c.mozpad if they have platform questions, even if this isn’t considered to be the “official” destination.
Mark Finkle posted an entry on the Mozilla wiki proposing a Mozilla Developer Day in Prague in the November timeframe along the lines of the one that took place in Paris in June. Reviews for the Paris day were glowing, but I know that a lot of people couldn’t make it and that others were left wanting more. If we can drum up enough interest, I’d also like to combine the Developer Day with a Mozpad face-to-face meeting. If there’s a chance you might attend, please sign up on the wiki so we can see whether the interest level is high enough to move to the next phase of planning.
Shane Caraveo of ActiveState sent me a heads up about their new Open Komodo initiative. This looks like a pretty big deal. They’re open sourcing portions of their Mozilla-based IDE in order to cultivate a community-driven development effort. Considering that many people have cited Komodo as a potential starting point for an IDE tailored to the Mozilla platform “if only it were open source”, this could be a big step towards my long-awaited Dream Firefox IDE. I’m looking forward to giving it a spin as soon as I get back to the office.
We had a great discussion on Wednesday about where to take Mozpad. Thanks to everyone who attended. Mukunda posted the transcript on his blog.
Some highlights from my perspective: we agreed that Mozpad should be focused on making Mozilla platform products more appealing to developers, but should not itself be a destination site for product information. Instead we should use the appropriate Mozilla websites (particularly MDC). I’d still like to have a nicer-looking Mozpad site to summarize our activities, who is involved, how to get involved, etc. Mukunda said he might be able to help make this happen since my graphical design skills haven’t developed much since fingerpainting in kindergarten.
Further agreement that there isn’t a XULRunner/WebRunner dichotomy. We can work on improving materials for both, and in fact there is considerable overlap (considering that WebRunner is a XULRunner application).
Personally I am planning to finish my API project and shift my focus to documentation, especially high-level descriptions of the products and why they are important. I’m hoping to find time to give some thought to what the XULRunner and WebRunner sections of MDC should look like. One of the various first steps is obviously to coordinate with the relevant documentation people at Mozilla. You know who you are. I’ll be in touch.
Hopefully we’ll see further progress on the outreach website(s) as well (the equivalent of SpreadFirefox but for the platform). Mark Finkle said he would try to get Asa to give us some guidance from his experience with SpreadFirefox.
Finally, we seemed to agree that Komodo was worth looking at in the context of a Mozilla platform IDE since they already have most of what we need. Discussions will continue once we’ve had a chance to take a look.
As I mentioned the other day, I’m grappling with the Mozpad mission, trying to find an encapsulation of our activities that is intuitive, useful and doesn’t overlap with activities that are already well served by other forums. In my previous post I suggested that we might take the platform under our wing and make sure that associated resources (white papers, the SDK, documentation, demos/samples, some sort of IDE, etc.) are accessible to interested parties without excessive trawling.
I had a long chat about this yesterday with Benjamin Smedberg and Mark Finkle (joined later by Robert Kaiser). I would strongly encourage anyone interested in the future of Mozilla, applications and the web to read the chat log. What came out of the discussion is a new hypothesis that all three of us appear to support: the importance of a C++ SDK is diminishing and the value of a platform for deploying web apps on the desktop is growing. I’m very sympathetic to this viewpoint, not least because I spend a lot of time coding in C++ (the verbose Mozilla dialect, that is), and I’m sure I’d be a calmer, happier, better grounded and more fulfilled person with more hair and lower blood pressure if I didn’t.
What this means, concretely, is that the platform to bet on may well be WebRunner. I can’t see any reason why something like WebRunner couldn’t be the basis for most if not all kinds of apps in the future. Naturally there’s a lot of work required to achieve this, not least implementing the relevant items from various people’s XULRunner wishlists to reduce (and ideally eliminate) the need for binary code in Mozilla-based applications and better integrate with the operating system desktop. (By the way, I used to be a proponent of replacing the desktop with the browser interface, but that was before I switched from Windows to Mac.) We need to figure out our strategy for local storage (Google Gears? mozStorage? A combination? Something else entirely?) We need to decide what the fate of XUL is, since the argument that “XUL is for desktop apps and HTML is for web apps” makes less and less sense as the boundary between the two blurs.
Anyway, I probably don’t have to go on about this too much since I made exactly this point in the conclusion of my Future of Applications essay. So alongside the “people-oriented” vs. “product-oriented” discussion, I think Mozpad needs to have a serious discussion about the relative merits of XULRunner and WebRunner and where we should be investing time.
|
|
|
