Wednesday, January 03, 2007
How truly open is Flash? Do we need "Open Flash"?
This is a post made by David Mendels that inspired me to get this message out. I too have noticed that a few people Still perceive Flash as a proprietary technology. If you are one of those, read this then ask yourself the two questions at the end. I had a completely different view of Flash before Adobe and Macromedia merged.
David writes:
(Some basic points)
David writes:
(Some basic points)
- The Flash programming language (ActionScript) is 100% ECMASCript, a standard with multiple implementations and is open. You can script using ActionScript with a plain old text editor.
- The internal Flash Player VM, “Tamarin” is an open source project run by the Mozilla foundation (donated by Adobe).
- The Flash file format, *.SWF is a published format.
- The Adobe Flash Player (the reference implementation) is free. So are several others like the Gnash player.
- The Flash Player is available on Mac, Windows, Linux, Playstation, Nintendo Wii, Symbion, and many other platforms.
- An SDK for building, compiling, debugging Flash applications is available for free on Mac, Windows and Linux
- There are over 100 third party, free, commercial, open source and closed source products that produce, edit, generate, and otherwise manipilate Flash files, Flash Video files, etc.
- There is a very active Open Source community around the Flash runtime. For better or worse (I do work for Adobe -;) many many people take full advantage of the Flash Player without using any commercial products from Adobe (or anyone belse). See http://www.osflash.org/ to get a good view of this.
- Flash itself makes use of several standards such as JPG, AVI, GIF and PNG's as outlined here.
There are numerous web based services (You Tube, BrightCove, etc) that convert to, host, deliver Flash Video without requiring the purchase or use of any commercial or proprietary technology.
Now, all that said, the Flash Player as a whole is not open source. There are a number of reasons for this, at least as of today. 2 primary reasons come to mind right now, but these are not immutable:
i. The desire to avoid bifurcation. Right now one can produce a SWF from any one of many tools/servers/services from many vendors and be 100% confident it will run across platform and across browsers. We experienced the impact of multiple slightly (or largely) incompatible implementations of HTML/JS browsers and of JVMs and both had a major impact to slow innovation and usage. One of the things our customers (developers/desginers/publishers) have told is us not to screw up the compatibility and ubiquity that have been the hallmark of Flash since day 1.
ii. There are technologies in the Flash Player for which we do not own the IP or the rights to open source it, for example, we have licensed our MP3 codec.
There is one more area where we are arguably not “open”. This relates to our licensing strategy on non-PC devices (eg Cell Phones). On these devices, we do license the Flash Player for a royalty to device manufacturers and telco operators. It is still free from an end-user and developer perspective, but there are a lot of costs associated with these integrations.
(...)
My experience is that when people say they want “open”, there are usually 3 or 4 things they really want or need:
* No lock in. They don’t want adopt a technology that they may get “blackmailed” to pay money for in the future. I think we have addressed this fairly well by making the Flash Player and SDK free.
* Integration. They want the technology stack they work with to work with the rest of their stack and tool chain. This requires appropriate use of standards (eg. we support XML over HTTP, Web Services, ECMAScript, CSS, integration with multiple IDE and Source Code management systems, etc) and well crafted and well documented APIs. I think we have this area covered too, but I’d like to hear about concerns.
* Leverage existing skills. By using standards, one does not get locked into skills that can not be found generally in the market and that will be obsolete in the near term. This is why we standardized on ECMAScript. This is why we have an Eclipse based tool. This is why we enable development with a purely ASCII text format to fit into other systems. This is why we leveraged CSS in the Flex framework, etc. I think we have this covered too, but I’d love to hear your thoughts.
* Ability to fix bugs/issues without depending on a vendor. From a tool chain perspective, one can choose to work in an entirely open source toolchain for the creation of SWFs, so this is covered. From the runtime perspective, this is arguably a barrier. That said, I don’t hear a lot of folks who have actual concerns about our “stewardship” of the Flash Player in this regard. I’d love to have your perspecitve.
Questions for the public:* What does “Open Flash” actually mean to you? Have we done a good job of balancing the interests of implementers and developers without hindering innovation?
* What specific problem(s) does “Open Flash” solve that are not addressed by our current “openness”
Comments:
Links to this post:
<< Home
I pretty much agree with everything you say here, and have echoed the same thoughts. For those who argue that it needs to be open, it seems more of a political - almost religious - argument than a practical one. It needs to be open so that anyone can go in and change or customize it. How many people are going to go in and customize and compile their own Flash player? Doesn't matter, they should be able to. ;)
I may be way off base, but I think some of the desire for it to be open source stems from the desire to develop/modify/deploy in a similar vein to PHP/Apache/MySQL.
Those open technologies have directly influenced the falling
costs of having a functioning web
platform. For 20 bucks or less, one can have a domain running with database and web app functionalities, and maybe a lot of folks would like for Flash to be the same way since it has become such an ingrained technology in todays interactive web.
Of course you have to really understand the whole Flash paradigm to get why thats easier said than done, and a lot of people just getting into it dont get the whole picture yet.
"you need Flash to do that"
"ok lets do it"
"well, actually we need to buy this IDE here for $700"
"what?! I got this website up and running for only $8!"
yes of course there are programs out there that make Flash files for cheap or free, but really, nothing even comes close to the ballpark of the real IDE.
Besides, are we talking about the public web user wanting it open sourced or developers only? For developers, one small job can pay for an entire state of the art web toolkit.
Bifurcation should be the bane of any Flasher, at any rate.
Those open technologies have directly influenced the falling
costs of having a functioning web
platform. For 20 bucks or less, one can have a domain running with database and web app functionalities, and maybe a lot of folks would like for Flash to be the same way since it has become such an ingrained technology in todays interactive web.
Of course you have to really understand the whole Flash paradigm to get why thats easier said than done, and a lot of people just getting into it dont get the whole picture yet.
"you need Flash to do that"
"ok lets do it"
"well, actually we need to buy this IDE here for $700"
"what?! I got this website up and running for only $8!"
yes of course there are programs out there that make Flash files for cheap or free, but really, nothing even comes close to the ballpark of the real IDE.
Besides, are we talking about the public web user wanting it open sourced or developers only? For developers, one small job can pay for an entire state of the art web toolkit.
Bifurcation should be the bane of any Flasher, at any rate.
Ahh - but the truth is that you don't need to buy anything to create Flash. If you want, you can code by hand using a text editor. Adobe's software value is in the ease of production. Take Flex for example. You can download a free MXML to SWF compiler from Adobe Labs and write MXML with a text editor, save it and compile it into a SWF. No cost involved.
Some non-openness:
1. The official SWF and FLV Specification license forbids writing your own Flash Player or video streaming server or any swf-reading program, using knowledge from the Specification. See the Restrictions section in http://www.adobe.com/licensing/developer/fileformat/license/
I presume Gnash, Red5, and other programs have used reverse engineering instead.
2. The bug list for the Flash Player is not published. I don't expect Adobe to publish security bugs, but some transparency for other bugs would be extraordinarily helpful. Numerous times, we have discovered Flash Player bugs. We dutifully report them in Adobe's tiny little "feedback" form and/or in the forums. From there they disappear in a a black hole. Known bugs are occasionally but rarely mentioned in support material. Many bugs have been present for years. Compare this with Microsoft's Knowledge Base articles, which document numerous problems and workarounds (or, much better, the Red Hat bugzilla database.)
1. The official SWF and FLV Specification license forbids writing your own Flash Player or video streaming server or any swf-reading program, using knowledge from the Specification. See the Restrictions section in http://www.adobe.com/licensing/developer/fileformat/license/
I presume Gnash, Red5, and other programs have used reverse engineering instead.
2. The bug list for the Flash Player is not published. I don't expect Adobe to publish security bugs, but some transparency for other bugs would be extraordinarily helpful. Numerous times, we have discovered Flash Player bugs. We dutifully report them in Adobe's tiny little "feedback" form and/or in the forums. From there they disappear in a a black hole. Known bugs are occasionally but rarely mentioned in support material. Many bugs have been present for years. Compare this with Microsoft's Knowledge Base articles, which document numerous problems and workarounds (or, much better, the Red Hat bugzilla database.)
# posted by 
: 3-Jan-2007 4:55:00 PM
: 3-Jan-2007 4:55:00 PM
My main concern in this is "shifting the goalposts".
Early on people said "flash isnt open cause swf isnt documented" (or "isn't documented fast enough"). Different people seem to want different things when they say "flash isnt open", which makes it hard to satisfy.
More on trying to pull out a functional definition here:
http://weblogs.macromedia.com/jd/archives/2006/12/open_requires_w.cfm
Chris Simmons asked to modify source like Apache, but Adobe Flash Player runs on Other Peoples Machines... you're looking for predictability there, not the ability to configure their machine! (You don't have to pay Adobe money to create SWF... check out Flex 2 SDK or osflash.org or other software houses.)
Someone who preferred to write anonymously (??) wanted to fork Players using Adobe's own source code -- see above. He closes with what I presume to be "flash will be 'open' when the engineering database is published", which is a step towards fixing the goalposts in place.ht
jd/adobe
Early on people said "flash isnt open cause swf isnt documented" (or "isn't documented fast enough"). Different people seem to want different things when they say "flash isnt open", which makes it hard to satisfy.
More on trying to pull out a functional definition here:
http://weblogs.macromedia.com/jd/archives/2006/12/open_requires_w.cfm
Chris Simmons asked to modify source like Apache, but Adobe Flash Player runs on Other Peoples Machines... you're looking for predictability there, not the ability to configure their machine! (You don't have to pay Adobe money to create SWF... check out Flex 2 SDK or osflash.org or other software houses.)
Someone who preferred to write anonymously (??) wanted to fork Players using Adobe's own source code -- see above. He closes with what I presume to be "flash will be 'open' when the engineering database is published", which is a step towards fixing the goalposts in place.ht
jd/adobe
To be clear, I actually did not ask for modifying the player source. Exactly the contrary. "some of the desire for it to be open source stems from the desire to develop/modify/deploy in a similar vein to PHP/Apache/MySQL". Guess I should have left out 'modify'. Thesedays, PHP and MySQL are most often just there and ready to go when you get a domain hosted. These two technologies especially together provide a lot of extra stuff to an otherwise static site, and you dont have to work too hard to do simple but useful with it even from a beginners standpoint. For Flash which adds more goodness, to be accessible in a similar way... thats what I think some people want.
I am happy with the way the Flash Player and paradigm in general look now and for the near future, and cringe every time I hear about open source SWF players.
And I do think Flex is cool, as is giving away the SDK, but its not accurate that Flash production is without cost just because the Flex SDK is free. Simply creating a SWF file doesnt equate with creating a "Flash" experience. It takes some zing, some tweens, you know, "Flashy". For anybody else besides experienced developers, to do Flashy stuff with the free compiler and framework will involve at least the cost of Flex Builder and some serious study time.
For example, I cant think of a free tool that even mimics the Flash IDE, where you can draw on a canvas, animate and add effects, then export to SWF.
So you can build a SWF file for free, but you currently cannot produce "Flash content" for free. Granted there are a lot of cheaper programs that will, so it can be done without purchasing Flash 8. But all those are lacking in some respect when compared with the Flash IDE.
Its like saying you'll give me the raw iron ore for free, but charge me 400 bucks to fabricate it into a set of wrenches for me. A really nice gesture, but what can I really do with it as is. Making useful Flash content with the SDK and a free text editor is not a cakewalk even for someone experienced with Flash.
So to recap, I think Flash is about as open as it should be, open sourcing the Flash Player would just really suck, and Flex is a great technology and toolset but not an open gate into Flash heaven.
I am happy with the way the Flash Player and paradigm in general look now and for the near future, and cringe every time I hear about open source SWF players.
And I do think Flex is cool, as is giving away the SDK, but its not accurate that Flash production is without cost just because the Flex SDK is free. Simply creating a SWF file doesnt equate with creating a "Flash" experience. It takes some zing, some tweens, you know, "Flashy". For anybody else besides experienced developers, to do Flashy stuff with the free compiler and framework will involve at least the cost of Flex Builder and some serious study time.
For example, I cant think of a free tool that even mimics the Flash IDE, where you can draw on a canvas, animate and add effects, then export to SWF.
So you can build a SWF file for free, but you currently cannot produce "Flash content" for free. Granted there are a lot of cheaper programs that will, so it can be done without purchasing Flash 8. But all those are lacking in some respect when compared with the Flash IDE.
Its like saying you'll give me the raw iron ore for free, but charge me 400 bucks to fabricate it into a set of wrenches for me. A really nice gesture, but what can I really do with it as is. Making useful Flash content with the SDK and a free text editor is not a cakewalk even for someone experienced with Flash.
So to recap, I think Flash is about as open as it should be, open sourcing the Flash Player would just really suck, and Flex is a great technology and toolset but not an open gate into Flash heaven.
To be fair, Adobe/Macromedia did a great job developing the present flash IDE from its early days until now. A lot of its concepts, ideas and designs stems all the way from the Authorware/ Director/ Action days and evolved along the way.
To ask them to open source that, presumably so that folks can compile, build and use them for free is like asking them to give their business away.
Come on guys ... :) You either give the content-creator, the reader, or none away, you don't give everything away, unless you are the content guys! ;)
Adobe is not a content-shop, so it has got to get its bacon from somewhere. The fact that they release the specs of SWF should pretty much provide what most folks need anyway. :)
In a similar vein as said above, open sourcing a project just for the sake of it, is sometimes not necessarily a good thing.
To ask them to open source that, presumably so that folks can compile, build and use them for free is like asking them to give their business away.
Come on guys ... :) You either give the content-creator, the reader, or none away, you don't give everything away, unless you are the content guys! ;)
Adobe is not a content-shop, so it has got to get its bacon from somewhere. The fact that they release the specs of SWF should pretty much provide what most folks need anyway. :)
In a similar vein as said above, open sourcing a project just for the sake of it, is sometimes not necessarily a good thing.
jd/adobe said: Someone who preferred to write anonymously (??) wanted to fork Players using Adobe's own source code -- see above. He closes with what I presume to be "flash will be 'open' when the engineering database is published", which is a step towards fixing the goalposts in place.ht
Hmm, neither of those is quite what I said. I was trying to give examples of how Flash differs from typical open software. I said the Specification license forbids you from writing your own player (or any program that reads SWF's). I didn't say anything about forking Adobe's own sourc code.
The Specification License is clearly written to protect the Player or Flash Media Server from being imitated. That protects Flash Lite licensing revenue (not the regular free player) and FMS revenue. These are as David Mendes mentioned.
In my case, I wanted to look at the Specification to learn about FLV metadata. But I couldn't read the spec without "contaminating" myself with restricted knowledge that would prevent me from using and possibly fixing Red5, etc.
As for the bug database, I'm not quite sure what you mean by fixing or moving the goalposts. Is that bad or good? What do the goalposts mark?
Let's go back to some quotes from from the original post (I'm not sure which parts are from David Mendes and which are from Duane):
3. The Flash file format, *.SWF is a published format.
Interesting, David (or Duane?) gives a link to a non-Adobe page describing the spec, instead of pointing to the official, license-restricted Specification.
Another quote from David or Duane:
Ability to fix bugs/issues without depending on a vendor. From a tool chain perspective, one can choose to work in an entirely open source toolchain for the creation of SWFs, so this is covered. From the runtime perspective, this is arguably a barrier. That said, I don’t hear a lot of folks who have actual concerns about our “stewardship” of the Flash Player in this regard. I’d love to have your perspecitve.
In the brief time I've used Flash to build some web-embedded audio and video players, I've encountered a number of bugs and oddities. If Flash were more "open", I'd expect there to be a published, detailed bug list somewhere. I would have been able to search it and pinpoint our problems a lot more quickly. Just as importantly, a public bug list would be a taking-off point for discussing what should be fixed quickly. Instead, the opaqueness of the "stewardship" (word in original post) of the Flash Player development and maintenance process forces us discover these bugs independently and then invent our own workarounds, and also not know whether there are plans to fix the bugs, and if so, when.
Just as an example: For years, Flash supported a limited number of MP3 sampling rates. In addition certain MP3 files would just not play, would play at the wrong speed, or would even crash the player. (I notice some of this has been fixed in the latest 9,0,28,0 player.) It would have been nice to know in advance about these undocumented limitations before we conceived certain applications. It would have been even nicer to know that a fix was under development or not.
Don't get me wrong: Flash has been generally great for us, compared with trying to wrestle with Windows Media Player, Quicktime, and Real Player embedded on web pages. But some aspects of open software I find very helpful (and not even open source code) are not present with Flash, and that is what I was trying to point out. I apologize for such a lengthy comment.
Hmm, neither of those is quite what I said. I was trying to give examples of how Flash differs from typical open software. I said the Specification license forbids you from writing your own player (or any program that reads SWF's). I didn't say anything about forking Adobe's own sourc code.
The Specification License is clearly written to protect the Player or Flash Media Server from being imitated. That protects Flash Lite licensing revenue (not the regular free player) and FMS revenue. These are as David Mendes mentioned.
In my case, I wanted to look at the Specification to learn about FLV metadata. But I couldn't read the spec without "contaminating" myself with restricted knowledge that would prevent me from using and possibly fixing Red5, etc.
As for the bug database, I'm not quite sure what you mean by fixing or moving the goalposts. Is that bad or good? What do the goalposts mark?
Let's go back to some quotes from from the original post (I'm not sure which parts are from David Mendes and which are from Duane):
3. The Flash file format, *.SWF is a published format.
Interesting, David (or Duane?) gives a link to a non-Adobe page describing the spec, instead of pointing to the official, license-restricted Specification.
Another quote from David or Duane:
Ability to fix bugs/issues without depending on a vendor. From a tool chain perspective, one can choose to work in an entirely open source toolchain for the creation of SWFs, so this is covered. From the runtime perspective, this is arguably a barrier. That said, I don’t hear a lot of folks who have actual concerns about our “stewardship” of the Flash Player in this regard. I’d love to have your perspecitve.
In the brief time I've used Flash to build some web-embedded audio and video players, I've encountered a number of bugs and oddities. If Flash were more "open", I'd expect there to be a published, detailed bug list somewhere. I would have been able to search it and pinpoint our problems a lot more quickly. Just as importantly, a public bug list would be a taking-off point for discussing what should be fixed quickly. Instead, the opaqueness of the "stewardship" (word in original post) of the Flash Player development and maintenance process forces us discover these bugs independently and then invent our own workarounds, and also not know whether there are plans to fix the bugs, and if so, when.
Just as an example: For years, Flash supported a limited number of MP3 sampling rates. In addition certain MP3 files would just not play, would play at the wrong speed, or would even crash the player. (I notice some of this has been fixed in the latest 9,0,28,0 player.) It would have been nice to know in advance about these undocumented limitations before we conceived certain applications. It would have been even nicer to know that a fix was under development or not.
Don't get me wrong: Flash has been generally great for us, compared with trying to wrestle with Windows Media Player, Quicktime, and Real Player embedded on web pages. But some aspects of open software I find very helpful (and not even open source code) are not present with Flash, and that is what I was trying to point out. I apologize for such a lengthy comment.
# posted by : 4-Jan-2007 7:33:00 PM
: 4-Jan-2007 7:33:00 PM
Absolutely no need to apologize for the length of a comment. This is good stuff that Adobe needs to hear. On the contrary, I want to thank you for taking the time to help us with this.
Duane
Duane
Hello anonymous,
Fair points: Those license restrictions do exist at this time on the file format spec. There is a case to be made that they protect against bifurcation of the runtime, something that is valuable not just to Adobe but also to the overall ecosystem, but one can also make the case you make as well. This is a regular topic of discussion here at Adobe and we'll keep looking at options here.
As for a public bugbase, also a good point. No specific announcements at this time, but I agree with you this would be a great thing for the ecosystem.
Regards,
David
Adobe
Fair points: Those license restrictions do exist at this time on the file format spec. There is a case to be made that they protect against bifurcation of the runtime, something that is valuable not just to Adobe but also to the overall ecosystem, but one can also make the case you make as well. This is a regular topic of discussion here at Adobe and we'll keep looking at options here.
As for a public bugbase, also a good point. No specific announcements at this time, but I agree with you this would be a great thing for the ecosystem.
Regards,
David
Adobe
one can guard against incompatibilities between forks ("bifurcation") by using trademarks in conjunction with a test suite. e.g. you can put down simple rules like "you can call your version 'Flash' or 'Flash-compatible' if and only if it passes these test suites."
sun used to bellyache about this issue in relation to java as well but eventually saw the light.
so ... what is the problem looking to be solved here? simple: on linux we still don't have a version of the newest flash player. for other operating systems, one needs to hope the linux-isms are minor and what there are can be covered by the native linux compat layer.
now, when a version of the player does comes out it usually only works with a couple of software packages.
wouldn't it be great if people could take flash and provide wrappers so that it works in other pieces of software as well?
and this is all to say nothing of bug fixes, bug identification, etc.
i think most of us would like an open sourced version of the flash player because we're tired of adobe not being able to service operating systems we use properly when there are developers happy to help you do this.
except that you won't let us.
sun used to bellyache about this issue in relation to java as well but eventually saw the light.
so ... what is the problem looking to be solved here? simple: on linux we still don't have a version of the newest flash player. for other operating systems, one needs to hope the linux-isms are minor and what there are can be covered by the native linux compat layer.
now, when a version of the player does comes out it usually only works with a couple of software packages.
wouldn't it be great if people could take flash and provide wrappers so that it works in other pieces of software as well?
and this is all to say nothing of bug fixes, bug identification, etc.
i think most of us would like an open sourced version of the flash player because we're tired of adobe not being able to service operating systems we use properly when there are developers happy to help you do this.
except that you won't let us.
Plenty of reasons, including the lack of true 64 bit compatibility support. If that's not enough, how about support for other architectures, like for those that want to run it on their strange hardware. Reason 3? How about waiting /years/ for an update. I'm surprised things didn't get started in gnash earlier. Truly sounds like a "company man" posting. You deserve a raise :}
I was trying to deploy an LTSP system a couple weeks ago on a dual core AMD 64 server. The primary reason we could not use a 64-bit operating system was unavailability of Flash.
We managed to get most things working eventually, but due to all the quirks of running both 32-bit and 64-bit programs on the same system, we ended up ditching the entire thing and going back to a 32-bit OS.
All because of lack of a Flash plugin.
That right there is a concrete example of why keeping Flash closed is a problem--there was nothing else in this company's entire application stack that forced us to install 32-bit software. An open source Flash could be compiled and distributed for other architectures and non-standard systems tomorrow, instead of not at all.
--John
We managed to get most things working eventually, but due to all the quirks of running both 32-bit and 64-bit programs on the same system, we ended up ditching the entire thing and going back to a 32-bit OS.
All because of lack of a Flash plugin.
That right there is a concrete example of why keeping Flash closed is a problem--there was nothing else in this company's entire application stack that forced us to install 32-bit software. An open source Flash could be compiled and distributed for other architectures and non-standard systems tomorrow, instead of not at all.
--John
I would have no problem if flash was
open in the sense of PDF. This is
clearly not the case currently and
this is also why I don't really have a fully functionnal flash player on
linux ppc. Linux is more than x86 you
know.
open in the sense of PDF. This is
clearly not the case currently and
this is also why I don't really have a fully functionnal flash player on
linux ppc. Linux is more than x86 you
know.
# posted by : 6-Jan-2007 9:31:00 PM
: 6-Jan-2007 9:31:00 PM
I'm a Linux user, but for practical reasons not for religions reasons. I work for a company that mostly does Web Applications hosted on Linux+Postgres. I did some early experimentation with Flash, but in the end my company and I have only used DHTML, CSS, and Ajax for creating responsive applications. We have had cusotmers on occassion ask about doing the same work on flash.
However, one reason I can't go with flash is because I have no way of knowing if the user has flash. Maybe it is easy to install on Windows and Mac, but with DHTML, CSS, and Ajax, I *know* that it works on all platforms out of the box (atleast with IE, Firefox, Opera, Safari and Konqueror).
As a web application developer who does not want to create applications with a "Requirents" section, I'd have to say that my requirements of "openness" would be such that that browsers could include and run flash out-of-the-box, just like PNG, CSS and Javascript. I think if you really think about it, that is what everyone needs and wants. Can you imagine if you had to install a CSS plugin before you could enter a website? It would be alot less popular.
However, one reason I can't go with flash is because I have no way of knowing if the user has flash. Maybe it is easy to install on Windows and Mac, but with DHTML, CSS, and Ajax, I *know* that it works on all platforms out of the box (atleast with IE, Firefox, Opera, Safari and Konqueror).
As a web application developer who does not want to create applications with a "Requirents" section, I'd have to say that my requirements of "openness" would be such that that browsers could include and run flash out-of-the-box, just like PNG, CSS and Javascript. I think if you really think about it, that is what everyone needs and wants. Can you imagine if you had to install a CSS plugin before you could enter a website? It would be alot less popular.
This probably has more to do with how Flash is implemented and delivered than the base technology, but Flash based content-sites have been consistently the most likely to crash my web browser, regardless of which browser I'm using. This has been the case for about the past five years across multiple hardware platforms and operating systems. If Flash was truly open, perhaps I could find an implementation that really worked. As it is, I only install Flash on my recreational computer, because the loss of stability is unacceptable for my work. When I'm trying to find information I need to complete a task, having my browser crash because of a buggy Flash advertisement on the page I need makes me very frustrated.
# posted by : 7-Jan-2007 8:18:00 AM
: 7-Jan-2007 8:18:00 AM
I am also a web developer who has looked at the option of Ajax vs. Flash. Clearly flash, as a technology, offers a much more mature and feature-rich platform to write rich client front ends. We ended up choosing Ajax for similar reasons to Henry. Ajax looks to become a _real_ threat to the flash eco-system, and I think this is exactly because it is based on open technologies that are subsequently covered by all modern browsers.
It has often occurred to me that an "open" flash that could be supported out-of-the-box by browsers would instantly trample the threat of Ajax. Moves like opening Tamarain are a good step in that direction.
It has often occurred to me that an "open" flash that could be supported out-of-the-box by browsers would instantly trample the threat of Ajax. Moves like opening Tamarain are a good step in that direction.
# posted by : 7-Jan-2007 9:20:00 AM
: 7-Jan-2007 9:20:00 AM
Good article, and kudos to Adobe for embracing open standards and trying to explore new models. That being said, a couple points:
On the lockin tip, it's not just about the cream, it's about sole stewardship and dependency. While Adobe is a fine company by most standards, there's no guarantee they won't become a bad actor at some future date from some perspective.
"Lock in" is ultimately about being locked-in, not just paying money. Just because you give me bread and circus doesn't mean I like your dictatorship, so to speak.
Also, the freedom to fork (what you "protect against" in terms of bifrucation) is an important aspect of open source projects. While it's often an ugly process, it's necessary to admit as a possibility if you want to allow truly decentralized innovation.
Lastly, as flash gets to be more and more popular/powerful and integrate with/replace more traditional "desktop" tasks (a possible, if by no means guaranteed outcome), the whole question of security and trust becomes much more germane.
On the lockin tip, it's not just about the cream, it's about sole stewardship and dependency. While Adobe is a fine company by most standards, there's no guarantee they won't become a bad actor at some future date from some perspective.
"Lock in" is ultimately about being locked-in, not just paying money. Just because you give me bread and circus doesn't mean I like your dictatorship, so to speak.
Also, the freedom to fork (what you "protect against" in terms of bifrucation) is an important aspect of open source projects. While it's often an ugly process, it's necessary to admit as a possibility if you want to allow truly decentralized innovation.
Lastly, as flash gets to be more and more popular/powerful and integrate with/replace more traditional "desktop" tasks (a possible, if by no means guaranteed outcome), the whole question of security and trust becomes much more germane.
keith peters: How many people are going to go in and customize and compile their own OS, or office package, or SQL database? So what's all the fuss about Linux, OpenOffice, MySQL, all the free software? Following this logic, they are complete nonsense, good only for a couple of religious geeks...
BTW, should we happily mistake "free as in free beer" for "free as in free speech"? If yes, this article is OK. But if no, then sorry - Flash Player is NOT free.
Practical reasons: aseigo pointed them better than I could. Thanks!
In short: Duane, thank you for convincing me that we really need badly Open Flash.
BTW, should we happily mistake "free as in free beer" for "free as in free speech"? If yes, this article is OK. But if no, then sorry - Flash Player is NOT free.
Practical reasons: aseigo pointed them better than I could. Thanks!
In short: Duane, thank you for convincing me that we really need badly Open Flash.
As other people have mentioned, running flash on x86_86, or PPC, or any random free OS/processor combo. With a closed product you are at the mercy of the vendor to assign priority to the port (if they do it at all). With an open source approach if enough people have that itch they can get it working regardless of if it meets the corporate mission. That the true power of open source.
I really think flash is a great technology. And, it seems to be moving in the 'open' direction.
But... Just like Sun was reluctant to open-source Java a while ago, Adobe still feels it has to have control over the Player/VM to protect it's cross-platform compatibility. A spec that you may not use simply is like a mirage to open source developers and will make it difficult for them to implement anything that comes close to the real Flash-player from Adobe.
This may be seen as an advantage, but people forget about what they are missing. For example: as soon as the entire Sun JVM will be available under the GPL Licence (which it probably will), it will become the JVM of choice for most of the Linux-distributions and other open projects. I expect a lot of effort that would otherwise go into making an open alternative to the Sun JVM available to go into the actual Sun JVM. This will guarantee that the Sun JVM will stay the most complete 'reference' implementation. There is no need to even create a slightly incompatible implementation. More architectures will become supported, which for Flash and Linux-AMD64 would have saved me a lot of frustration.
I think Adobe should do the same to the flash player. I can see it being in every product on the market, even the open ones (could come as a standard plug-in for firefox, maybe, that's a licence-type issue, i guess). This would even create more oppertunity for Adobe to sell it's fine software for creating flash animations and would make more and more solutions depend on their player. The difference will be that Adobe will no longer have the Flash-users locked in. But as long as Adobe will be doing what it should do (being best at creating flash-based solutions), i can see no need for forking the player or the risk of a different product being better at creating flash content. As i see it, it would be a win-win situation for Adobe and the opensource community.
But... Just like Sun was reluctant to open-source Java a while ago, Adobe still feels it has to have control over the Player/VM to protect it's cross-platform compatibility. A spec that you may not use simply is like a mirage to open source developers and will make it difficult for them to implement anything that comes close to the real Flash-player from Adobe.
This may be seen as an advantage, but people forget about what they are missing. For example: as soon as the entire Sun JVM will be available under the GPL Licence (which it probably will), it will become the JVM of choice for most of the Linux-distributions and other open projects. I expect a lot of effort that would otherwise go into making an open alternative to the Sun JVM available to go into the actual Sun JVM. This will guarantee that the Sun JVM will stay the most complete 'reference' implementation. There is no need to even create a slightly incompatible implementation. More architectures will become supported, which for Flash and Linux-AMD64 would have saved me a lot of frustration.
I think Adobe should do the same to the flash player. I can see it being in every product on the market, even the open ones (could come as a standard plug-in for firefox, maybe, that's a licence-type issue, i guess). This would even create more oppertunity for Adobe to sell it's fine software for creating flash animations and would make more and more solutions depend on their player. The difference will be that Adobe will no longer have the Flash-users locked in. But as long as Adobe will be doing what it should do (being best at creating flash-based solutions), i can see no need for forking the player or the risk of a different product being better at creating flash content. As i see it, it would be a win-win situation for Adobe and the opensource community.
# posted by : 7-Jan-2007 4:09:00 PM
: 7-Jan-2007 4:09:00 PM
2 years I have been waiting for amd 64 on linux. Had the flash player been open source it would have long ago been ported.
This is the sort of thing that affirms my hatred for proprietary software such as flash. Hopefully the
gnash project reaches maturity shortly here so we no longer have to deal with this problem again.
This is the sort of thing that affirms my hatred for proprietary software such as flash. Hopefully the
gnash project reaches maturity shortly here so we no longer have to deal with this problem again.
# posted by : 7-Jan-2007 11:18:00 PM
: 7-Jan-2007 11:18:00 PM
An open flash player should allow me to view flash content on my Power PC debian powered ibook and should have allowed me to see flash 9 content on my X86 ubuntu powered notebook & desktop last year before the availabilty of a beta non libre free of charge flash player. So the need for a open source player is needed not for religious or political purposes but just to access content for non proprietary OS users (Is it practical reasons or not?). Go for it Gnash! Free us from the "Not available for you bloody bastard Linux/BSD users" frustration syndrom.
For me it is pretty simple:
- There is an FOSS player which allows me to play content (preferable integrated in a FOSS browser);
- There is a viable and usable FOSS IDE to create content;
- No patent issues (like Mono has);
- Well documented.
As far as I'm concerned, everything else is proprietary. As a FOSS developer, I want to code (and document), I've got no time to concern myself with the nitty gritty legal baggage. Please note the Java-trap: Open Software that depends on a non-open tool (until recently).
If you want to be open, be open. If you want to make money out of software sales, do so, but don't whine you're not considered open. BTW, ECMA is a *BAD* example (Micro$oft dog).
Hans Bezemer
- There is an FOSS player which allows me to play content (preferable integrated in a FOSS browser);
- There is a viable and usable FOSS IDE to create content;
- No patent issues (like Mono has);
- Well documented.
As far as I'm concerned, everything else is proprietary. As a FOSS developer, I want to code (and document), I've got no time to concern myself with the nitty gritty legal baggage. Please note the Java-trap: Open Software that depends on a non-open tool (until recently).
If you want to be open, be open. If you want to make money out of software sales, do so, but don't whine you're not considered open. BTW, ECMA is a *BAD* example (Micro$oft dog).
Hans Bezemer
# posted by : 8-Jan-2007 2:02:00 AM
: 8-Jan-2007 2:02:00 AM
Both your reasons are really invalid:
i) compatibility: AFAIK, that was the reason why Sun maintained control over the Java specification for so long. History has proven this is a misplaced concern and Sun have moved over to GPL - which inherently protects against incompatibility.
ii) proprietary bits like MP3 - these are really not required for enabling sound. There are many proven, stable and high quality open implementations like WavPack, FLAC, Ogg etc. All of these have plugins/players for all OS platforms in current use on client machines.
i) compatibility: AFAIK, that was the reason why Sun maintained control over the Java specification for so long. History has proven this is a misplaced concern and Sun have moved over to GPL - which inherently protects against incompatibility.
ii) proprietary bits like MP3 - these are really not required for enabling sound. There are many proven, stable and high quality open implementations like WavPack, FLAC, Ogg etc. All of these have plugins/players for all OS platforms in current use on client machines.
# posted by : 8-Jan-2007 3:27:00 AM
: 8-Jan-2007 3:27:00 AM
Hi Duane,
I guess the answer to this depends on what you mean by flash.
Flash the specification: The specification not only needs to be free to access, but free to implement in any manner. Any limitation of how people can use information devalues that information - in the case of limitations on the flash specifications that limitation is so severe that if I read it my value as a developer would be reduced. It places a question mark over the legality of code I write in future if I do read those specifications. IMO Flash should also be using open standards for audio etc (such as ogg). By all means license the mp3 codec for use within your publishing/server software (this can be a point of difference - more of this later), but the actual specification should only include other specifications which also meet the standard of free (libre).
Flash the player: The player needs to be open source for a couple of reasons - the first is cross-platform support is only truly available with source code. I don't want to have to worry myself about ABI breakages, 64bit etc support. Providing the source means that it is guaranteed to be able to work with my system. By able I mean not that it necessarily will with your source, but the option is there to provide the necessary patches to enable support (whether that be taking care of 64bit issue or other). It is in Adobe's interest for a flash player to be as widely available as possible. It is not a commercially differentiating factor - it is an enabler for your technologies. If people can run flash applications on their choice of platform it makes flash more appealing and enlarges your prospective audience. So by opening it you increase your marketplace for your development and server software. I can understand your concern regarding the purity of the specification - as long as it is available freely people will work to it for widely distributed products. It is in their interest to do so because as soon as they start deviating from your established standard they run the risk of their product not being widely accessible - defeating the purpose of using the specification at all.
Flash the development (and server) tool: This in my opinion does not need to be free (libre). This is the point where Adobe differentiates itself. Your standard is available freely and widely through multiple platforms - so you're providing a development space with a broad target. Your goal here is to provide a superior development tool - the differences in this tool from the alternatives are what will make flash (generally) profitable for you. Making the workflow simpler, more efficient and other advertising spiel adjectives is what the development tool should be all about. It is in this space you can do things such as provide support for mp3s (which are published in an open format when the movie is exported). Same deal for the server side. Your product can provide interoperability between proprietary and free technology which in itself is a huge benefit. Coupled with the enriched developer experience you'll keep your market share.
If your concern is about a competitor making such a product then specify that any application which implements your free (libre) specification must also be free - this limitation is far less onerous (and will almost certainly be accepted by the free software community) than the current one.
Just some suggestions, but the thrust of this is that we don't need "Open Flash" we need "Free Flash" (the specification - as once the specification is free whether Adobe produces a free player or not becomes almost irrelevant - though you'd gain a large amount of goodwill by also doing so with the player. Once the specification is free there's little benefit for Adobe to not free the player).
If you'd like to discuss this more feel free to jabber me at this email address. (I assume you can access it).
Cheers,
Alan.
I guess the answer to this depends on what you mean by flash.
Flash the specification: The specification not only needs to be free to access, but free to implement in any manner. Any limitation of how people can use information devalues that information - in the case of limitations on the flash specifications that limitation is so severe that if I read it my value as a developer would be reduced. It places a question mark over the legality of code I write in future if I do read those specifications. IMO Flash should also be using open standards for audio etc (such as ogg). By all means license the mp3 codec for use within your publishing/server software (this can be a point of difference - more of this later), but the actual specification should only include other specifications which also meet the standard of free (libre).
Flash the player: The player needs to be open source for a couple of reasons - the first is cross-platform support is only truly available with source code. I don't want to have to worry myself about ABI breakages, 64bit etc support. Providing the source means that it is guaranteed to be able to work with my system. By able I mean not that it necessarily will with your source, but the option is there to provide the necessary patches to enable support (whether that be taking care of 64bit issue or other). It is in Adobe's interest for a flash player to be as widely available as possible. It is not a commercially differentiating factor - it is an enabler for your technologies. If people can run flash applications on their choice of platform it makes flash more appealing and enlarges your prospective audience. So by opening it you increase your marketplace for your development and server software. I can understand your concern regarding the purity of the specification - as long as it is available freely people will work to it for widely distributed products. It is in their interest to do so because as soon as they start deviating from your established standard they run the risk of their product not being widely accessible - defeating the purpose of using the specification at all.
Flash the development (and server) tool: This in my opinion does not need to be free (libre). This is the point where Adobe differentiates itself. Your standard is available freely and widely through multiple platforms - so you're providing a development space with a broad target. Your goal here is to provide a superior development tool - the differences in this tool from the alternatives are what will make flash (generally) profitable for you. Making the workflow simpler, more efficient and other advertising spiel adjectives is what the development tool should be all about. It is in this space you can do things such as provide support for mp3s (which are published in an open format when the movie is exported). Same deal for the server side. Your product can provide interoperability between proprietary and free technology which in itself is a huge benefit. Coupled with the enriched developer experience you'll keep your market share.
If your concern is about a competitor making such a product then specify that any application which implements your free (libre) specification must also be free - this limitation is far less onerous (and will almost certainly be accepted by the free software community) than the current one.
Just some suggestions, but the thrust of this is that we don't need "Open Flash" we need "Free Flash" (the specification - as once the specification is free whether Adobe produces a free player or not becomes almost irrelevant - though you'd gain a large amount of goodwill by also doing so with the player. Once the specification is free there's little benefit for Adobe to not free the player).
If you'd like to discuss this more feel free to jabber me at this email address. (I assume you can access it).
Cheers,
Alan.
Open flash to me means:
1. being part of any linux distro I install.
2. working on AMD64, Power, Sparc and anything else firefox or any arch that gui browsers work on, for Linux, BSD, Solaris etc.
3. having new versions the Linux, Windows and Mac versions released on the same day
4. Having the list of known bugs published and being able to comment on them.
5. Having the security peer reviewed by experts in computer security who contribute fixes or write about it.
6. Being able to report bugs in flash to Ubuntu, Redhat or whoever and have them sort it out.
7. Not being worried that you will have to some day pay for the flash client either though money or adverts, adware etc.
1. being part of any linux distro I install.
2. working on AMD64, Power, Sparc and anything else firefox or any arch that gui browsers work on, for Linux, BSD, Solaris etc.
3. having new versions the Linux, Windows and Mac versions released on the same day
4. Having the list of known bugs published and being able to comment on them.
5. Having the security peer reviewed by experts in computer security who contribute fixes or write about it.
6. Being able to report bugs in flash to Ubuntu, Redhat or whoever and have them sort it out.
7. Not being worried that you will have to some day pay for the flash client either though money or adverts, adware etc.
Hello Duane, i also agree with you. However there is one important limitation of the player which would go away if Adobe would opensource it. I am talking about the context menu. I am very dissappointed that regardless of many requests, to let to fully manipulate the context menu they still didn't change their way. I am a flex developer and i find it annoying that i am not able to hide the default items and that the context menu is not skinnable, which stands out from the rest of the application design.
If this problem would be solved, i really don't see any reason to opensource the player.
Best regards, Zoltan.
If this problem would be solved, i really don't see any reason to opensource the player.
Best regards, Zoltan.
# posted by : 8-Jan-2007 10:28:00 AM
: 8-Jan-2007 10:28:00 AM
For me the most common occurrence of the Flash Player are the nagware banners which you cannot turn off unless you have a mozilla ad-block plug in.
When I have too many pages open, my PC comes to a screeching halt. This is a nuisance.
It would be a great advancement if it were possible to turn it off in any browser without plug-ins.
Martin Jasny
When I have too many pages open, my PC comes to a screeching halt. This is a nuisance.
It would be a great advancement if it were possible to turn it off in any browser without plug-ins.
Martin Jasny
# posted by : 8-Jan-2007 1:09:00 PM
: 8-Jan-2007 1:09:00 PM
As so many others have pointed out, the similarity of the 'arguments' that Flash is 'free enough' to the same bull poop that recently stopped coming from Sun is remarkable. Free is Free, Open is Open and Flash is neither. Period full stop.
If Flash wants to be Open it needs to be possible to have a whole chain from content creation to playback using all Free/Open software. This isn't currently possible as a practical matter, although great efforts have been and are being made to solve the problem.
The great question is will Adobe Free Flash before or after it matters. Sun cut it very close, another year and nobody would have noticed their code dump because GCJ and Classpath would have been good enough. Once Gnash hits 1.0 it won't matter nearly as much whether Adobe opens the Flash Player.
Seriously. Would a distro toss a 1.0 Gnash for the crufty glop (Corporate codebases tend to be crap compared to public efforts) Adobe would spew forth with no bugtracker, mailing lists and proven support system and probably with important features needing to be reimplemented to cover holes left by licensed 3rd party software? Not likely.
Even worse, once a free flash player exists the clock starts ticking as to when Firefox bundles it. Or worse, what if MSFT did it. Yes they hate Free Software but Adobe is also a competitor. Gnash could become the defacto reference implementation.
Then the content development side needs to be blown open. Yes professionals might consider the cost of the official kit worth it, much like professional photographers don't balk at paying for Photoshop. Others find Gimp good enough and would likewise find a capable Free package good enough for creating useful content.
If Flash wants to be Open it needs to be possible to have a whole chain from content creation to playback using all Free/Open software. This isn't currently possible as a practical matter, although great efforts have been and are being made to solve the problem.
The great question is will Adobe Free Flash before or after it matters. Sun cut it very close, another year and nobody would have noticed their code dump because GCJ and Classpath would have been good enough. Once Gnash hits 1.0 it won't matter nearly as much whether Adobe opens the Flash Player.
Seriously. Would a distro toss a 1.0 Gnash for the crufty glop (Corporate codebases tend to be crap compared to public efforts) Adobe would spew forth with no bugtracker, mailing lists and proven support system and probably with important features needing to be reimplemented to cover holes left by licensed 3rd party software? Not likely.
Even worse, once a free flash player exists the clock starts ticking as to when Firefox bundles it. Or worse, what if MSFT did it. Yes they hate Free Software but Adobe is also a competitor. Gnash could become the defacto reference implementation.
Then the content development side needs to be blown open. Yes professionals might consider the cost of the official kit worth it, much like professional photographers don't balk at paying for Photoshop. Others find Gimp good enough and would likewise find a capable Free package good enough for creating useful content.
# posted by : 8-Jan-2007 9:35:00 PM
: 8-Jan-2007 9:35:00 PM
Let me sum up website usage of Flash in one word: Irriating!
Any company that creates their entire web page in flash is just doing things wrong. Flash takes longer to load, takes more resources to run, and makes web pages slow. That's why I have flashblockerinstalled in Firefox. Don't even get me started on the lack of an official flash 8/9 for Linux. I finally got the beta of Flash 9 to work, and then promptly blocked everything.
Too many ads! Too many ads are flash based. Ads create revenue for websites, but they are annoying and some ads are over board irriating. I'm more likely to click on a text link I can totally read and understand than any Flash link.
Finally, This Thinkpad has a P-III 500Mhz chip in it running Linux. It can play XviD and X264 movies with no problems with great visual quality, but it stutters when running flash. WTF! Let's get real here. Make we pages standards compliant(and IE IS NOT a standard) like Firfox and make them faster to load and easier to read and navigate. Not everyone has a Core2 or Athlon64. And most don't need one.
Any company that creates their entire web page in flash is just doing things wrong. Flash takes longer to load, takes more resources to run, and makes web pages slow. That's why I have flashblockerinstalled in Firefox. Don't even get me started on the lack of an official flash 8/9 for Linux. I finally got the beta of Flash 9 to work, and then promptly blocked everything.
Too many ads! Too many ads are flash based. Ads create revenue for websites, but they are annoying and some ads are over board irriating. I'm more likely to click on a text link I can totally read and understand than any Flash link.
Finally, This Thinkpad has a P-III 500Mhz chip in it running Linux. It can play XviD and X264 movies with no problems with great visual quality, but it stutters when running flash. WTF! Let's get real here. Make we pages standards compliant(and IE IS NOT a standard) like Firfox and make them faster to load and easier to read and navigate. Not everyone has a Core2 or Athlon64. And most don't need one.
# posted by : 8-Jan-2007 10:20:00 PM
: 8-Jan-2007 10:20:00 PM
Any technology can be used for annoying purposes. One of my favorite statistics I once saw (cannot remember the source) stated that over 90% of all website visitors hit the "skip intro" button. LOL. Makes you wonder why someone even adds this button.
Nevertheless, don't shoot the messenger. While the technology is great, the content is only as good as the author.
Nevertheless, don't shoot the messenger. While the technology is great, the content is only as good as the author.
# posted by : 12-Jan-2007 10:28:00 AM
: 12-Jan-2007 10:28:00 AM
Reading through existing comments, most of my issues are already listed. I am a linux user, and I always struggle with binary-only software. Will it work with my system? If I upgrade my glibc will it still work?
One issue I did not see commented on yet is DRM. Because of the closed nature of the flash player, I am not in control of my computing experience. The author of the flash movie I'm watching has complete control, which is not always what I want. Many of the little details that made the firefox browser more desirable than IE were related to putting the user back in the drivers seat. If the flash spec was truly open, and even more so if the flash player was open, I could expect a similarly user-configurable experience. This document talks about forks as though they are very bad, but I have to disagree. Forks in the spec are bad. Forks in the player are not. If the specification is truly open, only those who take the M$ approach of 'embrace, extend' would be interested in forking the spec. For the player, many different implementations could exist to serve different needs... but all could conform to the specification. As for the dev tools... I do not believe Adobe should provide them, either gratis or libre. It is through those tools that Adobe can make its money. With a fully open spec, other free and/or non-free dev suites may be created for those who are unable or unwilling to pay... but Adobe will have a good head start.
One issue I did not see commented on yet is DRM. Because of the closed nature of the flash player, I am not in control of my computing experience. The author of the flash movie I'm watching has complete control, which is not always what I want. Many of the little details that made the firefox browser more desirable than IE were related to putting the user back in the drivers seat. If the flash spec was truly open, and even more so if the flash player was open, I could expect a similarly user-configurable experience. This document talks about forks as though they are very bad, but I have to disagree. Forks in the spec are bad. Forks in the player are not. If the specification is truly open, only those who take the M$ approach of 'embrace, extend' would be interested in forking the spec. For the player, many different implementations could exist to serve different needs... but all could conform to the specification. As for the dev tools... I do not believe Adobe should provide them, either gratis or libre. It is through those tools that Adobe can make its money. With a fully open spec, other free and/or non-free dev suites may be created for those who are unable or unwilling to pay... but Adobe will have a good head start.
Flash is open when I can install a Free (libre) software player that is 100% compatible. Gnash may be what will make Flash open, but its developers will need access to the spec to be compatible. You should give it to them fast, because soon Gnash will be the default player on a lot of systems, and unless it is compatible by then you will have a incompatibility nightmare. A nice way to ensure compatibility would be to follow Sun's example and let compatible implementations use your trademark.
# posted by : 29-Jan-2007 4:00:00 PM
: 29-Jan-2007 4:00:00 PM
Open Source isn't what's important. The Flash player and the Flash development environment can be as closed source as it wants. Just as Microsoft Office is. Nobody wants an Open Source Microsoft Office (perhaps some do, but that's beside the point). What we want is a certainty that the stuff we produce with our tools will be open, not just now, but forever.
The only way to ensure that is to open up the specification and create an open standard. Just like PDF. Flash should be taken to ISO so that the specification(s) surrounding it can be ratified in an international standard. Seeing how important Flash has become and how much it's used, it would be devastating for Flash users if the technology should suddenly become closed or not maintained any further because Adobe shifts focus for whatever reason (mergers, sales, etc.).
If the specification is not open, it can't be developed upon once the original author and maintainer stops maintaining it. Also, Flash is so stable now that it should be possible for other entities than Adobe to give input to its future development.
The only way to ensure that is to open up the specification and create an open standard. Just like PDF. Flash should be taken to ISO so that the specification(s) surrounding it can be ratified in an international standard. Seeing how important Flash has become and how much it's used, it would be devastating for Flash users if the technology should suddenly become closed or not maintained any further because Adobe shifts focus for whatever reason (mergers, sales, etc.).
If the specification is not open, it can't be developed upon once the original author and maintainer stops maintaining it. Also, Flash is so stable now that it should be possible for other entities than Adobe to give input to its future development.
I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.
Ruth
http://fendisite.com
Post a Comment
Ruth
http://fendisite.com
Links to this post:
<< Home
