I’ve just come across this horror story about G-Archiver, a windows shareware which backs up your gmail account to your local hard drive but also emails your username and password to the creator!
When we initially launched AllPeers, the client was not open-source but we always said our goal was to do it. At the time, the source code was not clean enough to open but we knew this was the only way for us to prove we were genuine and not planning on spying on our users.
When we finally opened the code, some people saw it as a desperate move on our part. It was not. It was a way for us to be transparent and to say “if you don’t trust us, just look at our code”.
There are a lot of advantages about developing open-source software but trust and security are certainly high on the list.
Now forget about open-source software and think about all these websites who ask you for your login credentials in order to “import your contacts”. Can you really trust them and if so how? How paranoiac are you about this? I usually tend to trust the sites but is a nice design and a groovy name enough to earn my trust when it comes to my email credentials?
Mahalo founder Jason Calacanis caused a blogostorm with his candid treatise on making every startup dollar count. The controversy is not especially surprising when his list of tips for thrifty includes such items as “fire people who are not workaholics” (which provoked so much ire that he felt compelled to change it to “fire people who don’t love their work”). Some went as far as to label Calacanis a “prick“, with the obligatory observation that they’ve never heard or his company, but love to death the products of cooler companies who pay for their employees to go backpacking.
I’ve seen both approaches in action in my day. More than one startup founder has told me that they keep the hours reasonable because they “don’t want to burn out their staff.” Sorry, but what I heard was “I’m too lazy to work long hours so I can’t expect my staff to.” Of course, it depends to some degree on your ambitions. If your goal is to earn a good living with a bunch of smart, like-minded folks tackling some not-too-intractable problem, with plenty of free time to bungee jump from helicopters or make erotic origami, that is doable. But if you want to create a world-beating company, Mike Arrington has it nailed: your odds of succeeding are long enough without four-day weeks and ambling trips to the local juice bar five times a day.
Besides which, software geeks don’t have the same view of life/work balance as most people. In their response to Jason’s post, 37signals explain that:
Working with interesting people is more interesting than just working. If all you got going for your life is work, work, work, the good team-gelling lunches are going to be some pretty boring straight shop talk. Yawn. I’d much rather hear more about your whittling project, your last trek, how your garden is doing, or when you’ll get your flight certificate.
Probably the guy who wrote this is a graphic designer or something, since for all the real programmers I know, the most interesting subject imaginable is the software project they are currently working on. That’s why our social skills suck so bad. When we run into someone who isn’t a geek, we have no idea what to talk about. Naturally this gets old eventually, and even the pocket protector set ends up settling down, getting a dog and starting a family. Ever wonder why most startups are populated mainly with 20-somethings?
Which brings me to my real point: in light of this state of affairs, does Europe have a chance in the software biz? I’ve been working in European software startups for 15 years (and running them for 10). Having grown up in America, I’ve always been frustrated by the lack of obsessiveness when it comes to driving the company’s success. Programmers on this side of the pond work a lot harder than, say, post office clerks, but traditionally it’s still been a far cry from the mattress-under-your-desk workathon of the American startup nerd. When Arrington mocked the idea of “three weeks vacation” I had to smile. Over here, the big question is whether we can beat our staff down from five to only four weeks.
The good news is that the situation is changing. I’m seeing more and more startups built up around the American model. Globalization, more awareness of “cool” company cultures like Google’s and a few European home runs (such as Skype) are helping to reshape attitudes on this side of the pond. Lack of precedents for success, paucity of venture capital, stifling regulation and excessive risk aversion have conspired with our generally sedate work habits to lock Europeans into second-class citizen status in the software world. As we overcome these obstacles, I expect we’ll mount a much more credible challenge to America’s technological dominance.
Although AllPeers didn’t produce the kind of outcome that we had hoped for and expected, it’s been a tremendous learning experience. Hopefully others will be able to benefit from what I consider to be the main lessons.
Luck and ambition
Naturally the success of any startup is dependent to some degree on luck, and the luck factor rises in proportion to your ambitions. If your plan is to sell T-shirts online then execution is probably the main consideration. If you make really cool designs, have an easy-to-use website and do good marketing then you’ll probably make money, though you’re unlikely to be buying a private island in the South Pacific any time soon. If, on the other hand, you plan to dethrone Facebook by adding state-of-the-art social features to the fabric of the web, transforming the internet experience of billions of people, you’re going to have to execute to perfection and still get really really lucky if your company is to succeed. Of course, if you make it you’ll be assured a very comfortable early retirement.
Neither of these approaches is inherently wrong but you should be aware of what you’re getting yourself into. If you can’t stand the thought of failure, make sure you’re not tackling a problem that is too big and ambitious. In the case of AllPeers, we knew that there was going to be a lot of luck involved (as there is with any product that relies on network effects and viral adoption), and we were pretty well prepared for the challenges we would face. It is comforting to see failure in this way because we certainly wouldn’t have sacrificed our lofty ambitions to increase our chance of moderate success.
Raise as much as you can
I’m not the first one to say this, but let me express my wholehearted agreement: raise as much as you can, as soon as you can, and not a penny less. In early 2006, before we had released even a private alpha of AllPeers, we suddenly became a minor web star thanks to a couple of white-hot buzzwords (”Firefox” and “BitTorrent”) and a very positive writeup on TechCrunch. (And in fact we owe a great deal to Mike Arrington, who grasped our vision immediately and did a great job of articulating why it was exciting. It’s easy and intellectually lazy to be pessimistic before the fact and snarky afterwards, while it takes courage to go out on a limb and predict success.) We believed our own hype a bit too much, unfortunately, and didn’t take advantage of the opportunity to raise a lot of cash at a high valuation. Instead we brought in a very modest amount under the assumption that we’d be in a great position in a few short months to close a much bigger round.
As a result, we were under constant pressure to get user numbers up so we could raise more money. This isn’t the way to run a company, particularly one with an ambitious technological vision. We ended up making a string of tactical moves rather than taking a step back and looking at the big picture. As a consequence, we ran out of money before we could get the product to where it needed to be. Don’t make this mistake.
This shouldn’t be construed as a criticism of Mangrove Capital Partners, who led our series A investment round. They are a fantastic group of individuals whom I wouldn’t hesitate to recommend to any entrepreneur seeking funding, and a classic example of a VC who really does offer much more than money to a budding startup (something they all claim to do). But only a company’s founder has a single-minded focus on the company’s success, and this includes acquiring a war chest to deal with unforeseen contingencies.
Honza Odvárko, our user interface developer extraordinaire, has been doing some work on the excellent Firebug extension. He’s published the first two parts of a tutorial on extending Firebug on his new blog: Software is Hard (part one and part two). Anyone interested in developing and debugging web applications should check it out.
You think you’ve put it all behind you, but one tiny script and you tumble off the wagon. Such is the fate of the Greasemonkey addict. Someone mentioned yesterday that MXR search results should include a link to CVS Blame. (Regular readers of this blog are used to ignoring me when they don’t know what I’m talking about, right?) Rumor has it that real support for this is in the works, but I went ahead and wrote a script, just because I could. After all, the hallmarks of a good Greasemonkey script are quick-and-dirty hacks and planned obsolescence, and this one emphatically has both:
// ==UserScript==
// @name Add MXR blame links
// @namespace http://justdiscourse.com
// @description Add links to CVS Blame to MXR search results
// @include http://mxr.mozilla.org/*search?string*
// ==/UserScript==
var results = document.getElementsByTagName("ul");
for (var i = 0; i < results.length; i++) {
var ul = results[i];
var anchor = ul.previousSibling.previousSibling;
var span = document.createElement("span");
var blame = document.createElement("a");
blame.href = "http://bonsai.mozilla.org/cvsblame.cgi?&file=/mozilla"
+ anchor.href.substring(anchor.href.indexOf("/source")+7);
blame.appendChild(document.createTextNode("blame annotations"));
span.appendChild(document.createTextNode(" (View "));
span.appendChild(blame);
span.appendChild(document.createTextNode(")"));
ul.parentNode.insertBefore(span, ul);
}
Click here to install (Greasemonkey required).
It’s incredibly empowering to have this kind of client-side control over your browsing experience. One of these days someone is going to do this right and it’ll take over the world.
It’s a minor thing, to be sure, but it’s always irked me that Bugzilla defaults the platform and OS for a new bug to those of the reporter. This makes sense for bugs from “normal users” since it’s important to know where the bug occurred, but for the most part I file generic bugs or enhancements requests. So the first thing I have to do every time I file a new bug is to set those two fields manually to “All”. This takes me about five seconds, so if I file a bug a day (on average) that could be as many as 25 minutes a year. Twenty-five minutes that I could have spent taking movie quizzes on Facebook! This is unacceptable.
I asked around, and apparently fixing the problem is hard for some reason. Just now it dawned on me that I could take matters into my own hands. I used to be a Greasemonkey maniac, and I wrote a few pretty complex scripts back in the day. (None of these work anymore, I’m sure, due to changes in the associated websites, Firefox and Greasemonkey itself, but perusing the source code will bring you hours of enjoyment.) Wikiproxy and Bloglines Sidebar Squeezer even made it into Mark Pilgrim’s Greasemonkey Hacks.
Anyway, here’s the script I wrote to fix the Bugzilla nit:
// ==UserScript==
// @name Bugzilla Platform Defaults
// @namespace http://justdiscourse.com
// @description Changes the default platform and OS to ALL
// when filing a new bug
// @include https://bugzilla.mozilla.org/enter_bug.cgi*
// ==/UserScript==
resetDropDownList("//select[@name='rep_platform']");
resetDropDownList("//select[@name='op_sys']");
function resetDropDownList(xpath) {
var dropdown = document.evaluate(xpath, document, null, 9, null).
singleNodeValue;
dropdown.selectedIndex = 0;
}
Click here to give it a spin. (You must have Greasemonkey installed.)
UPDATE: Based on some discussion on IRC I probably should have given some more background to this post. In a nutshell, we are a Firefox extension and we store data in SQLite. For our extension’s user interface we want to generate markup (specifically HTML) from this data using templates that describe the page to generated, with placeholders for dynamic data. Something very similar to PHP, JSP, ASP, etc. in other words, but running on the client inside the Firefox process.
I’ve felt for some time that we need to change the way that AllPeers generates its user interface. For the most part, this is currently accomplished using a rather byzantine JavaScript-based framework loosely inspired by Eclipse. Experience has shown that this framework is a) rather slow, b) difficult for people to learn and understand and c) completely non-standard. At the same time, it’s proven challenging to find a viable alternative that meets all our requirements:
- Minimal code footprint
- Fast
- Support for recursivity (iterating hierarchical structures)
- Support for polymorphism (different template fragments for different types of data when iterating over a set)
- Support for streaming generated markup
- Execution possible in a background thread
-
- Simple syntax conducive for working with graphic designers
The last point rules out XSLT, in my mind, since it’s too difficult to work effectively with a graphic designer who creates static HTML pages. How are such pages to be maintained once they have been broken up into lots of little template rules? So we took a close look at the various open source templating engines out there. There are some appealing options based on Python, but we decided that shipping the Python runtime with AllPeers is not realistic, which narrowed the choice down to two C++-based solutions: CTemplate and Clearsilver.
Then I read a recent blog post by Mark Finkle, prompting me to look again at an option that’s been kicking around in my head for ages: using XUL Templates. When I first investigated this a couple of years ago, they didn’t appear up to the task, but substantial improvements have been made since then. The ability to graft straight onto a SQLite database, in particular, is of great interest to us.
The main issue I see with XUL Templates is that we may want at some point to move AllPeers to its own process, leaving only a thin UI layer in Firefox. This implies that our future template engine will have to generate markup to a stream rather than manipulating a DOM directly. In addition, we may want to do this in two phases, initially running the generator in a protocol handler inside the Firefox process. So it has to work on a background thread. To my knowledge, XUL Templates currently can’t do either.
Do we go ahead and adapt an outside framework like Clearsilver for our purposes? Or do we try to soup up XUL Templates to meet our additional requirements. I’d love to opt for the latter since I think these improvements might be of value to the Mozilla community at large. But it’s a tough call without knowing the answers to the following questions:
- Is anyone else out there interested in using XUL Templates to stream markup, run on a background thread, etc.?
- How much work would it be to adapt the XUL Template engine to our requirements?
- Is there a “third way” that I am missing?
Any input on either of these points would be greatly appreciated.
I’ve had some time to reflect on my recent musings about how to push forward innovation on the web without ceding dominance to closed, proprietary technologies. Several people pointed out that I was embarrassingly uninformed with regard to ECMAScript 4 support in Internet Explorer. The ScreamingMonkey project has been around for a while with the aim of achieving exactly that. And I’m so open-minded that I still think this is a fantastic idea, even though it apparently isn’t mine.
I read more closely what the Microsoft people have to say about the situation, and I’m actually finding myself sympathetic to both sides of the argument. Microsoft’s line is that a substantially revised JavaScript language doesn’t make much sense since there are already mature languages like Python and Ruby that could serve our second-generation web scripting needs. Backwards compatibility is all well and good, but people are still going to be reluctant to use new language features if they aren’t widely supported by browser vendors. I’m not a language designer so I can’t speak definitively about the challenges of supporting both ES3 and ES4 syntaxes, but this is bound to introduce a fair amount of complexity and redundancy into the scripting engine implementation. Simply adding Python support might be a more sensible path.
On the other hand, JavaScript has amazing mindshare on the web, and from a pure marketing standpoint it may be easier to achieve widespread usage of modern scripting constructs if they are promoted under the JavaScript brand. Moreover, Brendan has undoubtedly forgotten more about language design than I’ll ever know, and he is obviously convinced that ES4 will provide a smoother transition path than an entirely new language like Python. On a strategic level, Microsoft considers JavaScript to be a Mozilla technology, explaining why the former is eager to jettison it while the latter wants to see it reinvigorated. That’s how the market works (and works well).
The other pillar of the future web (and another favorite topic here on Peer Pressure) is markup. The shortcomings of HTML for application development (as opposed to document representation) are clear. At the same time, I find it hard to get too enthusiastic about XUL. This may be a case of familiarity breeding contempt, but in my experience XUL user interfaces are more functional than attractive. I’m not crazy about certain XUL features like XUL Templates, whose syntax strikes me as obscure. There are some very cool XUL-related technologies like XBL (if it had better error reporting), but the bottom line is that the idea of XUL on the web hasn’t gained much traction.
In the long term, someone like WHATWG may address HTML’s shortcomings as a language for app development. But as with the scripting debate, it’s worth considering whether there isn’t an existing language that could fit the bill. The obvious choice is Adobe’s MXML, which is used by Flex to build user interfaces. Whereas XUL UIs tend to be rather drab, the flashier Flex demos I’ve seen had me positively drooling. Adobe has already open sourced Flex, and it has donated its open source Tamarin virtual machine to the Mozilla project (something that still warms my heart every time I think about it). I’ve already blogged about Brendan blogging about a potential harmonization of XUL and MXML. And while Flex is still a relatively recent innovation, Flash continues to be astonishingly successful, and it’s reasonable to expect that Flex will be able to leverage to great effect the huge Flash development community and near ubiquitous Flash runtime.
Brendan Eich delivers a vicious smackdown to Microsoft for dissembling their motives regarding ECMAScript 4 (JavaScript 2). In essence, Microsoft is pushing back against ES4, claiming it is unnecessarily complex, while simultaneously touting its own full-blown web development framework (C#, .NET, Silverlight and friends). The reeks of hypocrisy and serves as further proof that Microsoft is continuing to employ its famous “embrace and extend” strategy on the web.
I can’t resist pointing out that, when I made a similar argument for improving web markup, the very same Brendan smacked me down for pragmatic reasons:
jgraham already pointed out the Prisoner’s Dilemma facing browser vendors trying to gain market share. Cooperate with the purity police while IE continues to defect? You lose.
Be that as it may, we’re all on the same side here, and the real question is how to push forward innovation on the web despite the daunting inertia of a billion legacy web browsers, most of which are controlled by a corporate entity that is pursuing its own strategic agenda. Whether we’re talking about better markup or better scripts, we quickly bump up against the “Prisoner’s Dilemma” that Brendan evokes.
I can see two possible solutions. One is a true paradigm shift. If people stop using web browsers as we currently know them in favor of, say, Rich Internet Application platforms like AIR or Prism, there will be an opportunity to deploy superior technologies that break with the past. In this scenario backwards compatibility is nice-to-have but not essential. For example, Google might decide to implement some future generation of Gmail on top of an RIA runtime in order to provide a more compelling user experience. In this case, I could easily see them opting for Mozilla’s open Prism technology rather than Adobe’s or Microsoft’s proprietary stack. If most people end up with Mozilla’s runtime on their machines, strategic control of web technologies would slip from Microsoft’s grasp.
The other option is to out-embrace and out-extend Microsoft. This might involve taking a page out of Adobe’s book by developing an ActiveX for IE that let’s users run ES4 and other goodies without having to convince Microsoft itself to play along. As it transpires, an ActiveX control for the Gecko rendering engine already exists, so there may not be too many technical obstacles to achieving this. Much more of a challenge, of course, is getting the deployment story right so that enough people end up installing the control in their browser.
The sad fact is that cooperating with web standards efforts that threaten the viability of its own strategic web initiatives is simply not in Microsoft’s interest, maddening as this may be. It won’t be easy, but pulling an end run around the Evil Empire and beating them at their own game is probably the only real option. And it’ll be oh so satisfying if we can pull it off.
I’ve come out of the closet recently as a big fan of WebRunner, so it was incredibly exciting to see Mozilla officially take the project under its wing with a great new name and branding. As far as I’m concerned, this is where the future’s at.
Since I’m all about putting my money where my mouth is, this raises the intriguing question of what it would mean to port a complex extension like AllPeers to Prism. We’ve certainly got a lot of mileage out of AllPeers as an extension, leveraging the full functionality of Firefox including the relatively easy extension installation process. Nonetheless, the need for explicit downloading and installation of a lot of code (mostly compiled C++) is a drag. Turning AllPeers into a true web app would remove all of the remaining friction for potential adopters.
The first question is how much existing functionality could be rewritten in JavaScript. Clearly JavaScript 2 will ease this task since it brings a lot of new programming constructs to the party that simplify the implementation of complex application logic. Tamarin is also a virtual must since its just-in-time compilation will have a major impact on performance. It should theoretically be possible to implement our entire resource management framework and networking layer in JS (although this would be painful since it implies rewriting a lot of existing code). I’m pretty sure some additional low-level networking code would have to be exposed by Mozilla, since we make extensive use of NSS directly.
The only remaining essential binary code in AllPeers is our codec support: we embed both FreeImage and the FFmpeg libraries in order to extract metadata from media files (height, width, length, bitrate, etc.) and generate thumbnails. With the work that Stuart Parmenter has done on Mozilla’s support for image encoding/decoding and the planned video and audio tags, it isn’t too much of a stretch to imagine a future Firefox where codecs can be installed in a manner similar to plugins and made available to JavaScript code. (Mike Shaver touched on this during his talk on future browser features at Mozilla 24.)
We also need some way to store our data in an efficient local database. Something like Google Gears would presumably fit the bill. It doesn’t look to me like DOMStorage will scale for a large repository of highly structured data, but I might be mistaken about that. I’m not sure how much traction (if any) Google Gears has outside of Google itself, but if it doesn’t catch on then some other persistent storage mechanism will be needed that gives applications control over the database at the SQL level.
The other issue that springs to mind is how to overlay AllPeers-as-a-web-app onto Firefox. We’ve had many people express interest in running AllPeers in a separate process, but a lot of the product’s appeal, in my opinion, stems from the fact that it is right there in your browser when you need it. This means that web apps need to be able to modify browser chrome: adding a sidebar, toolbar and status bar panels, at very least. This raises all kinds of security concerns, I’m sure, but at the end of the day if the app is written entirely in JavaScript with standard web privileges, it can’t do anything too heinous. Perhaps the biggest barrier is cracking the nut of dynamically loading and unloading overlays. This is tricky and it doesn’t look like anyone’s working on it right now. Hopefully someone will pick up the ball since this is, in my opinion, one of the biggest barriers to adoption of Firefox extensions in general. Perhaps the best approach would be to start a green field effort to enable web apps to modify the browser’s chrome in controlled ways, rather than trying to adapt the existing extension mechanism.
 I wrote a while back about our intern Luděk’s work on demonstrating how AllPeers can be extended by installing additional Firefox extensions that we call “extras”. The first extras added support for uploading images to Flickr and links to del.icio.us as part of the sharing process. They aren’t really ready for primetime, but they are good demonstrations of how one extension can extend another (in general) and how new features can be added to AllPeers (specifically).
 Since then, Luděk has been hard at work writing additional AllPeers extras. It is certainly a goal for these to be useful to some AllPeers users. With a bit of luck they will also be useful for those thinking about the requirements for adding real support for extension dependencies to Firefox. And, ideally, we’ll eventually see third parties motivated to write extras for AllPeers. You can see all the extras currently available on our new extras page.
As far as the Flickr and del.icio.us extras are concerned, it occurred to me recently that a better approach would be for these (and potentially other services) to be available in a way analogous to normal contacts. So I can share an image with my friends Bob, Fred and “Flickr”. The latter would result in the image being uploaded to their website rather than being shared via the AllPeers network. Luděk seems to agree so expect to see this in a future version.
 Another cool extra provides operating system shell integration. After installing it you get a new context menu option in your file manager to share files with AllPeers. This makes it quicker and easier to share files without having to go through a potentially cumbersome drag-and-drop process. It works both on Windows and on GNOME’s Nautilus, KDE’s Konqueror and Dolphin and XFCE’s Thunar (which I like to refer to collectively as “Linux stuff”).
 The final extra lets you set up a special user who will automatically receive any files you share. So if you have one machine that’s always on, you can install the caching user there and be sure that your files will always be available even if the computer you shared from (e.g. your laptop) isn’t. This is an elegant solution to the “no sources” problem that plagues all peer-to-peer networks.
I hope that these will be of both educational and practical value to others. I’ll blog about other extras as they appear. If anyone has ideas, drop me a line.
The Mozilla wiki describes in detail the ambitious plans for Mozilla 2. I heartily agree that the time is ripe for a major overhaul of the Mozilla engine. Considering the breadth of the planned changes, it’s worth at least asking whether the Gecko rendering engine, as it exists in Mozilla 1.9, is the right basis for this work. The wiki clearly states that Mozilla “won’t rewrite the Mozilla codebase by hand,” which seems prudent. But there is a second choice: replace Gecko with another rendering engine. Any viable alternative would, of course, have to be open source and match Mozilla’s battle-hardened robustness and standards compliance while offering clear advantages. This is a tall order indeed, but there appears to be at least one plausible candidate: WebKit.
The argument for WebKit
To someone like me whose business depends on the Mozilla platform, the biggest argument for WebKit is Mozilla’s large memory footprint. Developing on top of Mozilla has presented many challenges, but most of these can be overcome with time as the intricacies of the platform are mastered. The one that keeps me up at night is the tendency of Gecko-based applications to consume relatively large amounts of memory. My impression is that this is one of the main barriers to continued growth in Firefox market share, since it is of major concern to the digital cognoscenti who drive the technology choices of their friends and family.
Some of this is due to the way Gecko represents webpage DOMs in memory, some of it is a result of Firefox’s rich extension mechanism and some stems from the uneasy relationship between XPCOM and JavaScript. Like any software engineering issue, this could be solved with sufficient development effort. By all accounts, however, WebKit has a significantly smaller memory footprint, so its adoption would be the surest way to address this issue.
A direct consequence of Mozilla’s larger memory footprint is the difficulty of getting Gecko-based browsers to run on mobile devices. We’re witnessing a major shift in the center of gravity of browser usage from the desktop to portable devices. It is safe to assume that an ever increasing proportion of people’s browsing time will be spent on cellphones, PDAs and the like. Mozilla is facing irrelevance in this new territory as stakes are claimed by WebKit and Presto (Opera’s rendering engine). Once again, WebKit has amply proven its viability on mobile devices, most notably on the iPhone.
A less tangible benefit of dropping Gecko in favor of WebKit would be the pooling of community resources that would result from a rapprochement of the Mozilla and WebKit communities. There’s lot of work to do in the web browser space as web technologies become general-purpose software application technologies (a direction that Apple clearly supports):
- Local caching of code for offline operation
- A flexible storage API backed by a proper database engine
- Real-time rendering of 2D and 3D graphics
- Better forms with native widget support
- Strong online identity backed by digital certificates
- Application integration
- Peer-to-peer networking capabilities
- …etc…
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.
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.
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.
|
|
|
