shaver

I saw an article float by on the newscurrent yesterday, in which Adobe evangelist James Ward talks about misconceptions about Flex. This one definitely caught my eye:

Flash Player is 100% Proprietary.

The core of Flash Player is the Tamarin Virtual Machine, which is an open source project under Mozilla. While the SWF file format is not fully open, it is documented by the community on osflash.org. There are numerous open source products that read and write SWF files. The Flash Player’s product direction has traditionally been heavily influenced by the community and their needs. The core language for Flash Player is an implementation of ECMAScript 262, which is the specification for JavaScript. Flex also uses CSS for styling of components / applications. Adobe AIR uses web standards as the basis for desktop applications as well as Open Source technologies like Tamarin, Webkit, and SQLite.

We’ll ignore the wordsmithing genius involved in choosing “100% proprietary” as the misconception to address, and even let the non sequiturs about open source elements in other Adobe products go without much comment. Normally those things would rankle a bit, but in the light of the other gems present, I can’t really be bothered.

Gem the first:

The core of Flash Player is the Tamarin Virtual Machine, which is an open source project under Mozilla.

It is indeed true that Tamarin is a major piece of Flash Player 9, as it’s what runs the ActionScript language — but not the objects of the API! — and we’re quite glad that Adobe opened it up for us to develop together into an implementation of JS2. But I think it’s pretty misleading to imply that the majority of Flash is provided by Tamarin: it’s quite possible to have Flash that doesn’t use ActionScript, but everything relies on the implementation of the Flash VM itself — with its own bytecodes, graphics semantics, object model implementation and data management. The Flash VM is a huge piece of engineering, and one that Adobe has not opened up at all, though Flash artists have been clamoring for years to know more about the platform they invest so heavily in, to say nothing of people wanting to bring Flash capabilities to other operating systems and devices. Ryan Stewart also seems to think very little of the Flash VM, as he wrote back in October:

But I look at Adobe and what we’ve done. We’ve open sourced the guts of our runtime, the virtual machine. All that’s left is pretty much just the proprietary codecs and we’ve even addressed that somewhat with H.264 support.

All that’s left is pretty much the most significant piece of the Flash runtime, I would say, which is the engine that drives the complex graphics, provides the interaction model for ActionScript, manages data, and provides access to multimedia input and output. When they’re marketing Flash as a platform, Adobe likes to list out all the amazing graphical and video capabilities, but when they don’t want people to think too hard about the fact that writing to Flash is committing yourself to proprietary platform, I guess they aren’t such a big deal. Ryan’s comment on that very post indicate how important he thinks the graphical capabilities are for “RIAs”, but I suppose it’s more convenient to minimize them when people start asking questions about the mystery meat they baked into their applications.

Adobe doesn’t even permit people to use the specification to implement anything other than FLV tools, though the specification is written and published — just be sure you don’t read it, because then you’re tainted and can’t work on an open implementation of Flash, or open tools, etc.

Which brings us to gem the second:

While the SWF file format is not fully open, it is documented by the community on osflash.org.

This is quite the brazen comment. “The community” here are people who reverse-engineered the behaviour of Flash so that they could write tools to make the Flash Player’s platform more valuable, while Adobe’s license terms tried to stop them! They have put themselves in legal jeopardy in some jurisdictions (and Adobe has in the past had people arrested for producing tools that manipulate their license-protected technology) and James has the nerve to call them “the community” and indicate that their work is a remedy for Adobe simply not being willing to remove the field-of-use restrictions on their existing documentation. (I haven’t read the specifications, and I won’t, because I was warned off of them when I was working on gameswf, precursor to gnash.)

Mike Chambers called Mozilla’s announcement of Prism “disingenuous”, I think largely because he misunderstood the difference between “a more convenient way to launch a web app” and “a way to build non-web apps using the same technologies”. Maybe more about that craziness later, but for now I’ll be interested to see to what extent Mike’s concern for disingenuity extends to his own colleagues.

Right before Hallowe’en, Songbird 0.3 hit the wires, giving people an updated look at what the ‘nest denizens are planning in their webified music player. Right after Hallowe’en, Flock 1.0 arrived, featuring their “social” spin on the web browsing experience. Those teams have obviously worked hard and long to bring new and exciting things to the open web, and not to take anything that work, but these apps are also things that the rest of the Mozilla community should feel some pride in. Mozilla has always insisted on very liberal licensing of our technology in no small part so that people can innovate in different directions at the same time. Sometimes those innovations can come back into the shared code, sometimes they inspire other work, and sometimes they help generate experimental results that everyone can use to improve their own products and projects.

Are relations between all the different application developers and technology hackers and community members as great as they could be? No, though I think we’re all working to improve them as we learn how, and I think we’re getting better all the time. Our baseline openness helps a ton, and gives us a ridiculous amount of visible — though not always easy to digest — history of what the project has done, and why. We’re going to hear more and more about openness of platforms, technologies, organizations and processes as that becomes something that developers and users come to expect from the people they work with; I think the world and the web would be in a much better place if more of the players were open in ways that transcended specifications and publication of finished works. But then, I would think that.

More than a decade ago, JavaScript ushered in a transformation of the web browser from simple navigator of pages to platform for universal applications. In the intervening years, JavaScript has been standardized as ECMAScript, revised twice in that context to include things like exceptions and regular expressions, used as the basis for languages like ActionScript, and embedded in everything from web servers to DVD players to video games — and it’s become the most widely-used programming language in the world. It’s the big dog on the web, you might say.

What does one do for an encore, looking back at a decade of one’s language being taken to places scarcely imagined, used to build billions of dollars of value, and employed by millions of programmers around the world? I would like to find out myself some day, but for Brendan Eich, the father of JavaScript, the answer is clear: you make it better.

For the last couple of years, language researchers, application developers and web browser developers in the ECMA TG-1 committee — and Brendan, of course! — have been working to craft an evolution of the JavaScript language to remove headaches that modern developers are hitting and take advantage of the lessons learned over those years of watching people use and learn and love (and hate) the language. The result of that group’s work, and of the feedback of many developers contributing in the open, will be finalized soon as ECMAScript Edition 4. It represents a huge amount of effort, and the distilled wisdom of literally hundreds of people. And it represents an amazing opportunity for web developers to take their own software to the next level of power, performance, correctness and clarity.

What will developers have to do to take advantage of these things? Virtually nothing, to start: because of the relentless focus on compatibility and interop between JS1 objects and code, they will in many cases have things just start working faster and better because the authors of their favourite toolkits and tools have made use of new capabilities in the language. The specification has been improved to be clearer and easier to reason about, and had many bugs fixed, so things will work more consistently and it will be easier to use tools to manipulate JS programs reliably. The type system improvements give authors more control over how JS’s powerful dynamism affects their scripts, and will let them better preserve their important invariants, for security and correctness and performance reasons all.

And if you as a developer find that you’re hitting a limitation of JS1 that you want to get beyond, for reasons of performance or scale (developer-count as well as line-count or object-count), or because you want to use some of the new features to streamline your code, you can add those elements to your code incrementally. You don’t need to switch all your scripts at once, or worry about what happens when you pass objects between your JS1 widget library and JS2-enhanced animation library. The language developers have been worrying about that on your behalf for a long time, and they take these issues very seriously. Breaking the web is not an option, and there have been great (if grim) examples of what happens when languages with large installed bases forget that compatibility matters.

There’s a lot to talk about when it comes to JS2, and there are definitely a lot of new features and goodies for developers to adopt as they choose to. With JS1, Brendan and others managed to bring functional concepts, first-class functions and other relatively advanced language features to a straightforward and “newbie-friendly” language, and JS2 will bring more of the same accessible power to the millions of people out there who are making great software, large and small, in JavaScript.

I’m going to be writing more about JS2 in the coming days and weeks, because I think it’s one of the most exciting things coming to the web, and it brings new things in a way that I feel is very web-like indeed: incremental, compatible features based on real-world experience, developed in a collaborative standards environment with a pretty decent (though not yet perfect) level of openness. Look for more on JS2’s type system, where you’ll see JS2 available, more details about compatibility with JS1, and other neat things about the next version of the web’s scripting language. It’s gonna be fun.

Start your week by telling us what you think!

You have before you two quick opportunities to help Mozilla improve its documentation and show people how great the web is. Let them not pass you by, for regret will linger long after the hangover from Sunday’s partying has left you.

Opportunity the first: help Deb collect great examples of the power of the open web, by linking your favourite web stuff in her blog post. Bonus points for stuff that doesn’t require extra plugins, points may not be redeemable in your jurisdiction, no purchase necessary.

Opportunity the second: tell Sheppy which of the hundreds of documents on MDC you think are the most important, over in his blog post.

I’m late to this particular announcement, as I didn’t really have useful internet during the critical period last week, but that hasn’t dampened my enthusiasm one bit.

The Open Komodo/Snapdragon announcement is very exciting for me, and I suspect for many others in the Mozilla community. Having a basic, extensible IDE built on the same technology as Firefox (and therefore the web) will provide a great focal point for many of the IDE efforts that have been mooted around Mozilla technology over the years. People will be able to focus their energies on the specific tasks they wish to enable or improve, taking advantage of the incredible base that ActiveState has built.

I was lucky enough to be involved in the discussions and planning leading up to this announcement, and I think the most exciting thing about it wasn’t the prospect of the source release, though I am indeed eager to get that technology into the hands of the Mozilla developer community. The most exciting thing for me was seeing the depth of ActiveState’s commitment to the open web, and how enthused they are about helping to create a new open source community. This is a huge, huge investment in the open web by a small, small company, and I can’t wait to see where it’s going to take us — where we’re all going to take each other, in fact.

So thank you to Bart and Shane and David and Erin and all the others at ActiveState who had the vision and courage to make Open Komodo a reality, and to everyone who has already expressed their interest and support for the project. It’s going to be a blast.

Mark blogged about the new Firefox -app switch, which I think is a pretty interesting thing. Of course, it’s not a substitute for XULRunner, which gives the application developer complete control over important things like the update cycle and process, and it’s definitely not something that we’re recommending people use without a lot of careful study.

This is something that we’ve been asked to provide for quite some time, and even with the tight coupling to Firefox in versioning and launch syntax I think it’s going to be a valuable addition to the repertoire. Here’s how I now see the platform spectrum for our technology:

• Web applications. If you can do it here, you should. We’re working with other browser developers to develop and standardize new web-platform capabilities all the time, because being able to put your app in this bucket brings a ridiculously large number of benefits for users and developers both. With webrunner you’ll have a way to give users an optional desktop-launch experience that they may be more comfortable with, even.

• Firefox extensions. There are thousands of them that have been able to build great experiences (and, in some cases, great businesses) with products that are tied to the Firefox maintenance-update rhythm, and we’re seeing more great stuff all the time.

• Firefox “-app” apps. This is a nice little hybrid where you are still coupled to the Firefox update cycle and so forth, but get more isolation from the browser process and end-to-end control over the UI. As Mr. Finkle said, this is a sharp tool with its handle loosely attached, so please use care when using it. If extensions aren’t suitable for your project because of the update cycle model, then this very much won’t be either. For prototyping, or some extension-like uses, it’ll be killer, though. (I like that the apps are started with “firefox -app”, because it’s another hint that the thing you’re doing is dependent on Firefox, and that changes to Firefox could hurt it. I think it would be more confusing to have it be called “apprunner”, f.e.)

• XULRunner apps. I need say little more on this topic; Joost and Songbird and Komodo and Miro and…yeah.

By no means do we expect, recommend or condone XULRunner-grade apps being moved to this model without extreme care, but a lot of people building such apps, especially smaller ones, have been asking for a way to piggyback off Firefox’s awesome update story while still having their own top-level chrome.

The Firefox Developers Conference here in Tokyo is, simply, amazing. We have more than 150 people here, it’s very well-organized, and the simultaneous translation is basically a form of black magic. They apparently even did a great job with my keynote, and since my speed-talking is the sort of thing that translators use to scare their children into bed at night, I think you can perhaps appreciate how impressed I am. I’m hungry and tired, but the presentations have been well worth the long day. Mark and Justin did great presentations, and there have been some excellent discussions about AMO, extension localization, documentation, FUEL, and many other topics.

Also: I started to use Flickr to gather my photos from this trip, including some pictures from our trip to Tsukiji. I’m pretty pleased with my new camera, which does a pretty good job of hiding photographic incompetence.

On Sunday morning — they have a 6 in the morning now, which is an innovation that I’m sure benefits someone — I left for the airport to embark on a 16-day, 6-city, 41-flight-hour, 30,000-kilometre world tour. What got me out of bed that early in the morning? The same thing that gets me out of bed most mornings these days: helping people understand, contribute to, and benefit from the incredible power of the open web.

So I’ll be literally travelling around the world, meeting with partners and co-conspirators, talking to the press and developers, telling people what the open web is all about, learning how to tell that story in a compelling and energizing way, and trying to remember to stretch every few hours. Along the way I hope to hear a lot of other stories about the open web: its successes, its challenges, its surprising consequences, its possible futures. The open web is bigger than Mozilla, and the challenge ahead of us is to frame the discussion in a way that is inclusive of other perspectives, while staying true to the strengths and values which make the web such an amazing thing. And, more specifically, ahead of me. It’s an amazing opportunity to meet with some of the people who help make Mozilla a force for good in the world of technology, and I’m going to try to share the experience through my blog.

I’m boarding for Vancouver now to meet with ActiveState — who have been members of the Greater Mozilla Community for many years — coming from a brief visit in Boston featuring, among others, Nicholas Reveille of the Miro project (né Democracy). Already I’m seeing new challenges and opportunities for the web in areas of participatory video and media, and I’ve barely started on my trip. I’ll be in Tokyo and Paris at the developer days, in Munich and London to meet with press and other interested folk, and stopping in Denver and Frankfurt only briefly to sample their airport amenities. If you’re in one of those places and are willing to try to juggle with my full and fluid schedule, let me know and I’ll do what I can to meet up. I’m always excited to meet more Mozilla and web folks, and I’m usually a soft touch for a drink or two.

As my wife knows only too well, I can talk about Mozilla and the web all day, every day, and never get tired of it. I’m emotionally invested in the web, I take threats to its integrity personally and seriously, and I think there’s a fight brewing over the future of how people use technology to communicate, collaborate, do business, and share experiences. I hope to infect some people with my passion on this trip, and come back with a more comprehensive sense of what makes the web special to everyone else.

Mark had it exactly right: Mitchell’s post about XULRunner (and other things) was not an announcement that we are killing XULRunner. It was a statement about what the Mozilla Foundation is planning with respect to some very specific capabilities and deployment plans, due to our analysis of effort and return with respect to our primary mission.

To help people who might have been confused either by the original post or some of the reactions to it, I offer this summary:

• The Mozilla Foundation will not be working on the a shared, system-wide XULRunner deployment capability in the Gecko 1.9 timeframe. This means that applications which are built on top of XULRunner will need to ship a copy of XULRunner with their apps, or otherwise ensure presence of an appropriate one (version, build flags, etc.). This is, to be clear, what every XULRunner-based application is doing today. Many applications in fact ship with small patches to XULRunner in their distributions anyway, taking advantage of the open source nature of our platform to make different impact/value trade-offs than we do for Firefox, and on their own schedules. This is not to say, by any means, that we do not see the value in a future that includes a universal XR runtime, with appropriate versioning, update, profile-sharing and other wonderful capabilities. It is to say, rather, that we feel the investment required and the risk of destabilization isn’t appropriate for us to undertake directly during this development cycle.
• The Foundation will very likely not ship a “reusable” XULRunner as part of Firefox 3. While it’s still quite possible that Firefox 3 will be built on top of a private XULRunner, as outlined above, we will likely not take the schedule impact on Fx3 that would be required to make that private XULRunner usable easily by other applications.
• The Foundation is interested in supporting the production and distribution of “naked” XULRunner builds suitable for application authors to take, customize, and distribute. This is an area in which virtually any member of the XULRunner community (including those who are apparently very invested) can make a very helpful contribution, as members of the Eclipse AJAX group have done already in providing contributed builds. I believe that the SeaMonkey project, which the Foundation supports not through directly-tasked developers but instead through infrastructure and enormous investment in shared platform work, provides an excellent example. XULRunner’s very origin is from “outside the Foundation” in bsmedberg’s early work, and given the presence in the XULRunner community of funded companies like Songbird and Joost, I am confident that both the interest and ability to assist themselves and others in this area are present.

Other important points from Mitchell’s post, which deserve deeper discussion in other posts, include:

• A desire and commitment to invest in improving interactions with the entire XUL(runner) development community.
• A continued commitment to invest in the powerful and valuable shared platform for the web and beyond.
• A keen interest in improving the process of getting good and appropriate patches and other improvements (hello, docs and tools and build help!) into the common repository or pipeline promptly and predictably. As XULRunner itself is about 1000 lines of code that differs from Firefox, the bulk of the work is likely to be in build, packaging, update and other “meta” areas, I suspect.

(It’s the weekend, I’m off the clock; if I catch this attributed to “Mozilla”, as I saw people referring to my previous post, I will probably be quite cross. There is irony in that, but you shouldn’t feel compelled to comment on that.)

If people don’t stop link-dropping me Chris Messina’s performance art, I think I might have to hole up in a mountain cabin with automated weaponry and an ever-declining respect for personal hygiene. Don’t get me wrong, I think Chris is a pretty clever guy, and I’ve quite enjoyed the handful of real conversations I’ve had with him. He dances with the camera in a way that makes me a fair bit self-conscious, and he has Fortune Cookie 2.0 down so pat that I expect to open the BBC one day and find out that Venezuela is going to bust his patent and start making generics.

And I have a little of the manic in me too, so I can imagine how awesome it would feel to just Go like that: ranting into a recording for most of an hour, railing against enemies of the revolution; tossing half-formed ideas into the void (where they might contact the half-formed anti-ideas you threw in there 30 minutes prior — so much light); rubbing up against acceptable heresies until they’re polished and gleaming.

But if people are so starved for rah-rah web hope, if they so badly need something to Engage them, to let them feel like they’re glimpsing part of the Web Conversation, like they’re hiding under the tablecloth at the Cool Web Kids club holding their breath so nobody hears them over the gentle hum of pingback high-fiving and literary appropriation that they will spend THREE THOUSAND CONSECUTIVE SECONDS staring at Chris in a looking glass, taste buds a-tingle in anticipation of the next bon mot…. Well, damn, people. There’s work to be done. (Though, in all honesty, we’ve all sat through longer conference presentations that I’m sure were less thought-provoking and interesting. I haven’t even found time to watch Chris’ opus, but I’m pretty confident in this position.)

“Mozilla” can and probably will do many of the things I’ve read in people’s emailed excerpts of the FLV that Chris wanted to nail to the door of the church, because “Mozilla” is all the people who want to be part of it. People who agree that the Web needs a champion that isn’t going to try to slip something in their drink, a champion that isn’t going to ask you to pay to register once your free trial expires, a champion that tries every day to be a living expression of the web and sometimes succeeds. “Mozilla” is the people who build Spread Firefox and the people who dump it when they want to do something else. “Mozilla” is the people who write add-ons for Firefox and the people who will go to their grave improving SeaMonkey long after it was “supposed to be” gone. “Mozilla” is the people who help their friends and co-workers not only use Firefox but understand what that choice means. “Mozilla” is the people who mix their pronouns and metaphors because they’re terrified and proud and excited and can’t make all the things they feel about the web fit into text. “Mozilla” is the people who understand that telling Mozilla what it should be doing is like saying “nobody in my neighbourhood cares about the litter” but not picking up a piece. Chris didn’t need permission from a centralized authority to drive Spread Firefox, even ignoring the odd dichotomy of “you should make a centralized decision to drop SF so that you’re…not acting as a centralized decision making body”, he just needed to be willing to take action that might not succeed, and that would put his beliefs and goals out, in a concrete way, where people could see and judge them. He just needed to be willing to make the hard economic (scarcity, not prime rate) decisions about where to spend his time even if people were telling him he should spend it somewhere else, and I’m pretty glad he was willing. It’s scary as hell at times, and it’s a ton easier to tell people what they should do than to do what you think should be done — I speak from decades of experience here — but talk can’t change the web, can’t protect the web. And the web needs changing and protecting, make no mistake about it.

So if there are other aspirants to Ze Frank’s throne out there who want to spend an hour energizing the blogeratisphere and getting fitted for a pulpit — and I’ll be honest, you’re almost certainly not going to do it as well as Chris, unless you are actually Ze Frank — I encourage you instead to make a screencast showing someone how to use a part of Firefox, improve a document for a web developer near you, test an add-on from the sandbox, help someone make their web site work better with Firefox and SeaMonkey and Opera and Camino and Safari and all the other standards-oriented browsers out there, test a nightly, participate in any of the bazillion discussions about where the browser and platform could and should go. Do something that you think “Mozilla” should be doing, because if you’re on the web, and you care about the web, and you’re afraid that we might yet again have a monoculture of stagnation on the Internet, you’re “Mozilla” — even if you don’t know it yet.