Worth a quick comment, Air for Linux has an alpha release up and ready for you to try out.
From Adobe Labs: "Our main goal for this release is to begin to get the base features in place so you can share your early feedback and begin testing your Adobe AIR applications. This alpha is not feature complete. For a list of the specific features included in this alpha release, please see the release notes. "
Please take a moment to download it, try it out and give us feedback!
Today, the Ecma International Technical Committee 39 (TC39) announced it will focus work on the next ECMAScript standard, which will be known as “Harmony” and on ES3.1 (ECMA-262 Edition 3.1), with full collaboration of all parties involved in the subgroups of the TC39 (ECMAScript) committee. Work on ES3.1 will unite the committee in its work to create the next Ecma JavaScript standard, targeting two interoperable implementations by early 2009.
Adobe thinks this harmonization effort is a good thing. However, some blogs and comments have come out with the perspective that Adobe has “lost” the standards battle on ActionScript as a standard.
So let’s try to set the story a bit straighter.
Adobe (and Macromedia before) has been part of the revitalized ECMAScript efforts for a long time. The evolution of ECMAScript after the publication of the now current ECMA-262 in December 1999 [http://www.ecma-international.org/publications/standards/Ecma-262.htm] had stalled and as the web evolved, it was clear that the standard needed to be re-examined. Macromedia was a key part of that restart.
Standards (as I’ve mentioned before) do not drive innovation; rather they are desirable for setting a baseline of commonality. Since ActionScript is based on ECMA-262, it made sense for Adobe to offer it as a point for consideration as a basis for starting discussion on the next ECMAScript.
Unfortunately, as is the case with many standards, the situation became a tug of war. Standards aren’t just about the good of the community; they are also now recognized as competitive advantages. A new standard for ECMAScript thus became mired in a morass of bickering, infighting, and sometimes, out and out name calling; the politics of competition. It became clear that members could not arrive at the consensus needed to allow a decade of advancements to be incorporated into the next generation of ECMAScript.
Adobe is for standards. Standards make it possible to interoperate, intercommunicate and build rich experiences. I’ve stated that openness is like a conversation, in that we need a standard basis for understanding. We’re aligned with the needs of the web in stabilizing ECMAScript. This harmony will allow at least some improvements, updating of the existing standard, and for us to all be able to “talk” on the web with every one.
However, the web has evolved, and innovation is needed to continue to deliver rich applications and access to information. Adobe will continue to provide innovative technology through continuing to advance ActionScript (which, as mentioned, itself is based on ECMAScript).
We’ve already taken the steps to make sure that this innovative technology is available to everyone through release to open source of the Flex SDK, BlazeDS and the Tamarin VM (the virtual machine for ActionScript ). Open source is yet another aspect of being open. Open source powers innovation, just as standards tend to stabilize commonality. Using the conversation metaphor, open source allows us to talk in ways we might not have had in the past, whether it is in new words or new jargon. We’ll continue to work with all the groups, such as Open Ajax Alliance, Eclipse, Linux Foundation, as well as the standards groups defining the web.
In short, we agree with the necessity of the Ecma TC39 ES harmony effort. We’ll continue to be involved, in both ES Harmony and in future generations of ECMAScript. We will track Ecma efforts within ActionScript but won’t stop innovating ActionScript, which millions of developers rely on and is key to so many incredible web experiences today. It’s in our charter to make it possible to push the limits of what can be done on the web. We’ll continue to work with and for the community of folks who want to build the best the web can offer.
I invite you to join Adobe and myself in a conversation about where the web is going to evolve, built on a stable, mainstream base of standards.
It is to laugh.
In reading about the OpenSSH issues with Debian, one of the trails of pointers led me to a comic online, xkcd. A few comics later was this:
One coffe powered spit take later...
(and fair warning Microsoft Ninjas, Eric has guns!)
It's time to step up and volunteer folks. It's obvious that Verizon needs a Advisory Board at the highest levels.
Based on the comments from Sean Michael Kerner on internetnews , the Verizon CEo doesn't understand the impact of open source, or even can successfully parse the question.
What's even more interesting is this report from Cnet, "Verizon switches programmers to Linux" So in spite of saving millions in 2002, the CEO doesn't recognize open source.
Or this one from linux-watch, in which Linux is chosen as the Verizon mobile platform.
My CEO can tell you what open source is. I suspect yours does too.
Anyway, I'm more than willing to serve a couple of years to help the good folks at Verizon understand the impact open source can and does have on their business every day. And I'll even throw in some free consultations to the board.
There seems to be a lot of angst over the fact that the SWF specification is only covered by copyright. So lets take a moment to discuss this.
I'm not a lawyer, though I get to spend a lot of time around them in relation to standards and open source work. So here goes.
First, the specification is a document. It describes the SWF file format. It's like a book (albeit a short one). You, the reader don't need a license to read a book.
Open nearly any book and you'll see a copyright notice basically saying you can't copy the book. Same thing here
In fact, let's think of this as a cookbook. There are some pretty interesting recipes (SWF, FLV/F4V, AMF) that are there. You can certainly bake a SWF "cake" based on the recipe, and you don't need our permission to do so. You might have to buy some exotic ingredients that the recipe calls for to get it exactly like the lovely illustrative pictures, but you don't expect the cookbook to contain all your ingredients. And while some places provide ingredients for free (such as Tamarin or Flex SDK), not all ingredients are equally free (just as codecs aren't free even to us).
You buy your ingredients (or grow them, if you wish), you use the SWF recipe to bake it, and voila, a SWF-powered application.
Now, as with nearly every product, specification, etc around, there's other interesting text. Trademarks, references to other links, no offer of warranty on the contents. Again, absolutely normal. If you build it, you can't call it by our trademark names. If you use someone else's materials, we aren't responsible for the contents. (Here, think of using a oven to bake that cake. We aren't responsible for bad eggs someone else sells you, nor if you mislabeled salt as sugar). And it's absolutely standard for no warranty to be extended. Your "cake" is completely under your control, and we aren't responsible for how it turns out.
SO, no copyright traps. Feel free to write your own software that implements the specification. Since the specification does not include source code, you can't infringe our source code.
So, we'll look into ways to clarify the issues, but bottom line is that the specification is open and ready for you to cook up a storm.
