Flash has obviously been very beneficial to them in the long run. It has given them the only remaining well-controlled proprietary piece of the web. This helps them sell their IDE, and more importantly, gets their brand out there.
Now, I'd argue that these goals have now been accomplished. Adobe is well-entrenched in web history, and everyone knows what Flash is. However, the relevance of Flash is clearly declining, due to HTML5, and stigma and disgruntlement is increasing. This means they will get less and less sales of their IDE and their name will fizzle out.
Imagine for a second that they open sourced the Flash player. Just the player. Suddenly it would no longer carry such a stigma with Linux, it would be easy to include in distros, developers would contribute fixes and make it more efficient on hard-to-support systems. It would literally stretch out its life-time as a product, and keep Adobe's name on the web.
I argue that Flash has played out its role for Adobe, and if they open source it now it could only benefit them. I did not think this was true in the past, and I think it will not be true in 5 to 10 years when HTML5 has surpassed Flash adoption in the most important venues. However, right now I think it would benefit them immensely.
There also seems to be a sentiment from some of the comments here that they are losing interest in maintaining Flash, so opening it to the community would seem to make some sense. If the "standard" ends up evolving in any way, they'd always have a head-start in their IDE support, since it will easily remain ahead of the curve.
So one might say they should open source the core of Flash, the JIT compiler and virtual machine, and not the parts that are licensed. And you're right, that would be the correct move! They did that in 2006: http://en.wikipedia.org/wiki/Tamarin_%28software%29
They also open sourced the Flex SDK: http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK
What Adobe needs is a completely new product that is available to consumers for free, has it's source code public and free from patents. This way, Adobe tools can still be sold and used to develop, while the player is ubiquitous and as widely spread as possible. And that's what they're trying to do with HTML5: http://www.adobe.com/solutions/html5.html
Adobe's communication to developers is bad. No one knows about any this. Technology isn't their problem, marketing is.
EDIT: Make link a link :-)
The fact of the matter is that if Flash had opened itself up earlier, there wouldn't even be an HTML 5 Canvas/WebGL as we know it, people just would have used and extended Flash and Adobe would still be making bank on their commercial IDE for the environment. Now Adobe's dominance is threatened and Flash is universally despised.
Adobe is obviously terrible at maintaining the runtime so I think the only logical explanation for their lack of OSS Flash Player is that they have some very prehistoric business guys somewhere along the way that don't understand open-source at all and choke this off in terror every time it gets mentioned.
So here are my questions for Adobe:
Is there still income from Flash Player licensing? If not, how does keeping the Player closed source help your business interests?
Is it the client side DRM you have in place in the Player that's stopping you from making it open source?
Do you not have the resources to communicate with the community that would develop around an open sourced player (knowing that you would have spend some time to justify many things that exist in the codebase to maintain backwards compatibility)?
Are you concerned that a rival would clone some of the technology you developed and implement it in their proprietary player (e.g. MS, but they already gave up on Silverlight)?
Would the sudden influx of new security patches as vulnerabilities are discovered and fixed potentially compromise the performance of the Player?
Are you worried that individuals with malicious intent will find new vulnerabilities and exploit them?
What are your other concerns that are preventing you from open sourcing the Flash Player?
Google pays lots of money for Adobe to auto opt-in Flash installs with Chrome.
My understanding of that arrangement is that it is a mutually beneficial relationship that guarantees that Chrome users have the latest version of Flash (and Chrome is thus more secure) and the Flash Player update adoption happens faster. It makes very little sense to me that Google would pay Adobe for that since Adobe benefits just as much as Google.
Now how much money this brings in, who knows.
Note that this is NOT the same as Flash being bundled with Chrome. This is Chrome being bundled with Flash.
Streaming video will work just fine with HTML5 or just an old fashioned browser video plugin. A lot of the Flash web games will be missed, but my sense is that the vast majority of those people are using Windows and Mac.
The day is coming when very few new projects will be started in Flash and it will go the way of Silverlight.
So technically the code is Open Source but each distributor must get a patent license... that is restricted to redistributing binary form only.
(I deliberately did avoid the use of the word Free Software, as this actually might not be true if the code is licensed under the Free Software license GPL).
"Free Software" vs "Open Source" would not be relevant here, since both FS and OS would view this "you-still-need-a-patent-licence" clause as incompatible with FS & OS.
There are a few bits in the new GPLv3 that say "if you release under GPLv3 then you have to give everyone a patent licence". However I don't know how that works if you don't have a full patent licence…
There are existing open source implementations of H264. Even the best encoder (x264) is open source. But I guess there are license issues with third party code/libraries used in Flash.
It's a shame that a complete clean room open source implementation (e.g. x264) might still be illegal to use in some territories.
Sounds like what Oracle did with OpenOffice.org. Dumping it on the Apache Foundation and all that.
This is an effort to render SFW inside the browser.
The thread (which continues into May) goes over pretty clearly why they felt Pepper was a bad idea.
Given that linux really hasn't been a priority for them and they are dropping flash all together; this isn't really news.
The press release says Adobe worked with Google on Pepper. So for them to have a bias towards it isn't groundbreaking.
This is what's hard to understand: they are not dropping NPAPI on Windows, so it's not like the Chrome API is the enabler here.
This all assume there is actually going to be something more than security updates after 11.2 for other platforms. And that it is going to be something we would want on Linux.
Correct. The NPAPI version of Flash is very platform-dependent; whereas Pepper Flash is almost completely platform neutral, and Chrome OS needs most of the same Pepper platform bits anyway. So, our maintenance overhead for Pepper Flash on Linux is very small. On top of that, Linux is broadly deployed throughout Google (and is very popular among Chrome developers), so we're scratching our own itch a bit.
There will be updates and they will be desirable in Linux assuming people continue creating Flash content that makes use of the new features: http://news.ycombinator.com/item?id=3621096.
Keyboard input support in full-screen mode
Improved audio support for working with low-latency audio
Ability to progressively stream textures for Stage 3D content
LZMA compression support for ByteArray
Frame label events
ActionScript workers (enables concurrent ActionScript execution on separate threads)
Support for advanced profiling
Support for more hardware-accelerated video cards (from 2005/2006) in order to expand availability of hardware accelerated content
Improved ActionScript performance when targeting Apple iOS (What the??? iOS???)
Performance index API to inform about performance capabilities of current environment
Release outside mouse event API
Refactoring and modernizing the current core Flash runtime code base
Work on the ActionScript Virtual Machine
Updates to the ActionScript language
Doesn't seem like there will be anything new that can not be currently albeit less efficiently.
Robert O'Callahan talked in that thread about the potential for extending the capabilities of Web Workers to allow the kind of things you want to do to be done asynchronously. I know I'd love to have the ability to render to a 2D or 3D canvas context in a Web Worker, for example (the kind of thing that sandboxed plugins want to do), but all the effort that could have gone to that went to this weird plugin- (and NaCl-)specific API instead.
It's kind of sad, because I would like to use these APIs in my web content, but I can't. The cynic in me would say that it's because Google wants to push NaCl. I don't want to program C++ to get access to these goodies; I want to program in CoffeeScript.
You gave the example of using canvas from a web worker. Unfortunately, the whole web platform is built on the assumption of a single-threaded execution pipeline. Web workers get around this by using postMessage and not having access to the DOM, shared variables, and other stateful parts of the platform. Canvas and WebGl as spec'd and implemented are tied to these stateful parts of the platform (DOM, etc.), which is why you cannot use them from a worker.
So, your desired change would involve either a major overhaul of the web as spec'd and implemented, or a change to the Canvas and WebGL standards. The first is probably not going to happen. The second is achievable and implementable, but wouldn't help address the use cases I described in my first sentence.
It requires no more engineering effort than it took to implement the corresponding code in the PPAPI, and probably a lot less. Moreover, non-NaCl and non-plugin code could benefit from it.
Maybe I'm really confused because I don't understand.
Here's some further reading:
Note that Darin's followup message included this:
"I do agree however we want to keep Pepper APIs in sync with existing Web APIs. That will obviously be a challenge if they are not one and the same, but I don't think it is impossible or even that difficult to achieve with them being separate APIs."
This has already failed. Web Workers cannot render even 2D content asynchronously today, while Pepper can (which advantages plugins and NaCl over ordinary Web content). This is exactly the problem that roc and smfr were trying to avoid.
Also, the argument that "it's an existing plugin, you don't want them to rewrite their code" doesn't hold water. It's an entirely new set of plugin APIs. Adobe has to rewrite its code anyway. It's just that the other browser vendors wanted the Web as a whole to benefit from this, not just Adobe.
Now, they're going to continue working on Flash, but only on a new API that is implemented only in a single browser in Linux (and from statements from Apple and Mozilla, will stay that way), but keeping it compatible with the old NPAPI on Windows?
What I don't even....
Edit: Could it be that Google is planning to release (or has released) some Linux-based appliance where Flash support is a must?
Flash is appealing because it has features HTML/CSS/JS do not have and because everyone on every platform has it. Since mobile devices are becoming ever more important and Flash is not supported on those devices (or will not be) the second part of that sentence is no longer true.
Conclusion: Flash is dead. We will have to deal with it for years but it's on its way out. A web technology that will not work on mobile devices has no future.
Flash may well survive as AIR - that’s an uphill battle but it's possible – but that’s kinda irrelevant for the web.
If you were on Wikipedia you'd see a [Citation needed] here.
The real question is if this is true, why are they dropping flash for android?
“First, there’s Open… Rather than use Flash, Apple has adopted HTML5…” — and CSS3, SVG, and HTML5 have indeed provided most of the capabilities that once were Flash’s domain.
“Third, there’s reliability, security and performance.” — which is really three things, each of which Flash has an outstandingly poor track record with.
“Fourth, there’s battery life.”
“Fifth, there’s Touch. ¶ Flash was designed for PCs using mice, not for touch screens using fingers. For example, many Flash websites rely on ‘rollovers’…”
> Google declared Flash dead in Chrome for Android.
This is excellent news for web security. It will force other browsers to at least implement the Pepper API. Hopefully it will encourage them to use Native Client as well.
If you see the arguments against Native Client, it's also obvious using it to be able to keep supporting Flash would be rather...ironic.
You're saying Google is enforcing whatever it wishes upon others. Aka, non-standard stuff.
The Pepper API would be all nice if it wasn't hiding the NaCl vessel. NaCl is a very hard to standardize (yes, being open source has nothing to do with ease of implementation, or proper standards. News at 11.).
NaCl is also (one of) the vessel for Google to get more control over the web, due to the above, and that it can do stuff such as "take your C/C#/etc. app and run in it Chrome, via Chrome market!", while they know others can hardly ever implement it.
you can be relatively sure that Google pushed Adobe a little bit in that direction, and that eventually flash may be Pepper API only. Its easier for Adobe too.
the Flash Player browser plugin for Linux will only be available via the “Pepper” API as part of the Google Chrome browser distribution and will no longer be available as a direct download from Adobe
> Because of this work, Adobe has been able to partner with Google in providing a “Pepper” implementation of Flash Player for all x86/64 platforms supported by the Google Chrome browser. Google will begin distributing this new Pepper-based Flash Player as part of Chrome on all platforms, including Linux, later this year.
It says that the plug-in will be bundled with Chrome, and Adobe have said they won't be releasing more Flash players for Linux, but the announcement does not even hint whether a stand-alone Pepper plug-in will be available from Google. I hope the Chromium blog will clarify this in due course.
I guess Adobe might forbid Google from developing a plug-in, but I don't see why they would want that, seeing as they have been distributing plug-ins for years. If Google could but didn't, that would make them look unsupportive of Chromium.
If the Adobe blog post is correct and the pepper plugin is only distributed with Chrome and isn't open source and part of Chromium then how is another browser going to support it? They'd have to tell you to install Chrome and then open the plugin from within Chrome's installed directory. Pretty ugly solution.
If it's open source and part of Chromium then they can at least take the source out and ship their own, assuming the licensing allows for that and is compatible with their license.
All in all, this sounds like a pretty complex scenario for non-Chrome browser.
Meanwhile, Flash continues to circle the drain, and this might hasten its inevitable, but slow demise.
They might simply shift to Chrome as their default browser.
1) Adobe is effectively stopping work on Flash for Linux on their end; it's just not worth it to them.
2) Google is going to support Flash for Linux for Chrome specifically. They can do this because they have access to Flash source and because the Pepper version of the plug-in is much more cross-platform than the NPAPI version, so the support effort is not too great. Given that they already ship a modified Flash, not the stock one, it's not that big a difference from what they're already doing.
So I think you're wrong; even if other browsers implemented the Pepper API, they would also need source licenses from Adobe or would be dependent on Google to get the Flash plug-in.
Perhaps it'll kill Flash a bit quicker considering the amount of Kiosks and Internet cafes running Firefox+Flash on Linux.
You must not watch many videos in your browsers then outside the odd one on Youtube. The reality out there is that Flash is still the main choice for delivering video. Flash is a necessary evil. It may be dying but for many it's still necessary and its removal from Firefox removes significant usability for its users.
And if iPad sales are any indication I don't think it's as big a deal as you make it out to be.
If I write some software that costs $999 and only works on HP/UX, it's not "Fuck Microsoft" or "Fuck Apple". It's "Fuck me."
I think they call it cutting off your nose to spite your face.
Flashblock plugins are ridiculous by requiring you to blacklist or whitelist flash domain instead of web domain. The former happens to be on CDN and suddently you can't do it :(
So the only thing non-Chrome-using Linux users will miss out on are things that use the new features of Flash introduced after that date.
Plus the older hardware I run Linux on can barely show a 288p Hulu video, with lots of stuttering, even though the machine can play videos twice that resolution flawlessly in any of the native video players.
Before recentish versions of Firefox, a Flash crash would bring down the whole browser.
Meanwhile, Flash is dead, it just hasn't stopped kicking yet. It's been a long decade, but many people will be cheering it and kicking the corpse when it finally shuffles off to the great /dev/null in the sky.
(It's sometimes used for in-house stuff, but then what isn't?)
F* Adobe: just kill Flash already, for good. The world (wide web) will be a better place.
I feel absolutely no love for Adobe. Flash was a great technology and Macromedia was a dream company (at least for 14-year old me). They ruined Flash and other Macromedia inventions after taking over.
I truly wish Adobe dies alongside Flash. And Oracle also.
Perhaps Adobe has to continue supporting Chrome to support Googles Chromebooks.
In a perfect world, we would have open standards and would never need to rely on a company. Hopefully flash will die quickly (I wish I had a dollar for everytime I have heard this).
While WebOS stuck with the open technologies, the next Apple phone introduced closed-source binary application as the main third party extension platform. If WebOS could make the open web technologies work as primary development method on a phone, why did Apple go back to the installable programs of the last century?
Google's Pepper is at least open standard with an open implementation, while I don't have any way to run iOS apps on any other platform than those tightly controlled by Apple themselves.
Strangely, we can look to Microsoft for providing an open standards HTML5 based version of an app like "Cut the Rope": http://www.cuttherope.ie/ -- imagine if iOS devices ran HTML5 apps well and this game (which sold 3 million copies on iOS!) was HTML5 from the start. You could run it on the iPhone or any Android device or your desktop right from the start.
Or do plugins like flash have the choice between native client and just using a shared library as they did and Pepper also supports that?
In the first case it would basically mean that flash would run sandboxed (and maybe on every system supported by Pepper, so once ARM support is added it could run there as well again). But probably with some speed-hit (~5% according to the documentation)
> Shumway is an HTML5 technology experiment that explores building a faithful and efficient renderer for the SWF file format without native code assistance.
> Shumway is community-driven and supported by Mozilla. Our goal is to create a general-purpose, web standards-based platform for parsing and rendering SWFs. Integration with Firefox is a possibility if the experiment proves successful.
Don't underestimate how complicated it might be to explain this to "noobs", though.
Starting 5 years from now, when Adobe actually drops support for Flash on Linux, right?
We'll see how much video and other stuff still requires Flash in 5 years. With any luck, not much.
I forsee a slow and painful death for Flash.
But, if major Linux browsers implement Pepper API, on the other hand it will mean that we (the users) won't have to bother installing (deb/rpm/etc) packages every now or then. Maybe it will turn out better.
Just another step in pushing Chrome down everyone's throat.
I can't imagine what Google hopes to accomplish with this since Flash is currently circling the drain, relevancy-wise, but if it does anything to hasten the move away from using Flash at all, then it's a plus.
This looks like the sort of heavy-handed monopoly activity that made Microsoft so great.
It's possible that Adobe were intending to cease all Linux-based browser support and Google prevented that by buying back Chrome support; in which case Google has slipped in their PR big time.
So really, the only things I'm missing are flash games I don't play and ads I don't watch. (Some flash games actually sort of work, but it's not dependable.)
The only YouTube videos I occasionally can't watch are the embedded ones. Clicking through to the YouTube page, however, solves that problem.
Source? Or is that just conjecture?
ie. if other browsers decide to support the new plugin API, will Adobe also support them too?
Adobe has stated (not in any press releases, but from the mouth of employees) that they will work with any other browser wanting to implement the same API.
Not holding my breath though.
And it seems like the days of sites implemented entirely in Flash have pretty much come to an end.
Given the nature of Flash I could never understand why it was so much trouble to implement on Linux, or to create a 64-bit version. I can't imagine what a colossal mass of spaghetti code that app must be. I've been waiting impatiently for it to die since at least 2001.
"Adobe and Google Partnering for Flash Player on Linux" — zzZZZ, good for them
"Flash For Linux Will Only Be Available For Chrome" — Holy balls, Flash is really dying, isn’t it?
So long as Google's Youtube defaults to Flash, it's a case of mutual interests.
Adobe gets free auto-updates and there is no hassle or extra steps for users, since there is only one way for them to effectively use it. I'm sure if Firefox were to support Pepper that they would make it available in a PPA or something.
For Adobe's part, I wish they'd be a bit more transparent, but regardless, I think I'm good to go with a pretty wide and stable cross-browser feature set today and will be that way for a while while JS frameworks play catch up. And meanwhile, good luck getting an IT dept at a fortune 500 to upgrade all their browsers to the latest version of firefox or chrome and to make that a requirement to use your software. And what would you gain by doing that today exactly if that's your target market?
What can HTML5/JS do today for RIA's that flash can't do better, faster, and cheaper?