the only difference between a file format and a standard is that with a standard multiple people agree to use the same file format.
That's nice but not really relevant since USD isn't a file format or a standard.
It does provide a (both binary and ascii) file format but it is much more than that, that alone isn't particularly useful. USD itself is a scenegraph format and provides c++ libraries and python bindings for modifying that graph. You also don't have to just use usda and usdb files, in theory you could write a plugin to support any kind of file format you like.
How long would you expect it to stay that way before profitable companies get their own IPOs?
How long is a piece of string? I'm not going to speculate on the many different things that may or may not happen in various scenarios. Just that what you speculated here is not what is happening given the way the new organisation has been structured.
There are two independent sets of developers, the graphic driver developers and the developers who actually use the API.
And the OpenGL extension methodology serves both. Developers can utilize the new features of new GPUs when they know what they are targeting and developers targeting broader audiences use core profiles.
The graphic developers may love that they can extend OpenGL to make use of their random new fangled features in their graphics card
That's good, you don't want to have to wait until a new feature is incorporated into the standard before you can use it.
but the developers actually using the API now need to check for some huge number of custom extensions that may or may not exist.
No they don't, that's what the core profile is for. If you want to target a broad audience then use that.
The whole draw of OpenGL was that developers could just add in the effects they wanted and allow users to turn them on/off to improve looks/performance. You weren't reliant upon the static/unflexible capabilities of APIs like D3D.
Except that the world changed and most of the "effects" shifted away from the underlying fixed function pipeline and into the programmable hardware which removed the inflexibility.
Now they're just playing the copycat game, and ignoring their biggest strength, to truly push GPU hardware to the limit.
This is about pushing GPU hardware to the limit, they are removing the generic resource management implementations that reside in the driver and force applications to suffer significant overhead by being unoptimized (hence the reason drivers are so large and that driver releases often include optimizations for AAA titles). The GPU resources are now under the direct control and management of the application which can take full advantage of the GPU rather than relying on the generic driver implementations.
Not so sure about that, it could become like Berkshire Hathaway where a single company controls multiple companies, each with their own publicly traded stock
Except that it couldn't be clearer:
"Alphabet Inc. will replace Google Inc. as the publicly-traded entity and all shares of Google will automatically convert into the same number of shares of Alphabet, with all of the same rights. Google will become a wholly-owned subsidiary of Alphabet." From the blog post
I want a micro-tablet. I want a cell phone without the phone to hold my shopping list, music, and podcasts. I don't want the phone.
Why doe this not exist?
It does. But most devices include the phone anyway because the cost is trivial and it's not worth it to create the tooling and manufacturing to produce a separate product which is basically the same thing without the phone.
So, because it's not going to work everywhere, it has no value?
No, it fails in its mission of being cross-platform when it doesn't support the most popular smartphone in the world and indeed the platform of one of the biggest content providers.
Just because it's not helpful to iOS users doesn't mean it's useless to everyone.
But the only thing you have given me that is even close to a real life example is of iOS users trying to migrate to Android.
I expect that we'll see better integration not from Google directly, at least not initially
Ok so you have no sell to Google, the MAJOR platform vendor and you have no sell to Apple the other major platform vendor...not a good start.
Amazon would be an example of such a vendor as it clearly benefits them.
Amazon is a TERRIBLE example, they benefit from selling you apps, if you can move to their platform without buying your apps from them that's pointless to them.
Again, for developers, the advantage is an expanded market
Rubbish, your key selling point for this is so that people can move platforms without buying their apps again, a net loss to developers. Targeting other platforms is trivial, it's a problem nobody has, as you pointed out already it's so trivial you can wrap it in the installer for Android.
Revenues from repurchased apps are signal noise.
Citation? I'll bet this is yet another thing you haven't done your research on though.
Transitioning from one platform to another while keeping your data is no different than transitioning between devices that use the same platform. Locally stored
data merely needs copied.
And where on the local storage is the app data stored exactly? Tell me exactly what I need to copy from Android - and where - to Firefox - and where. You're overlooking the important details that cause these things to fail.
Proof of what? I still have absolutely no idea what you're trying to accomplish.
That people don't want it. It's there and people aren't using it. And you are still begging me to give you some validation that users want it.
Rubbish. "Wizbang 3000", "SpiffyOS", "Neat-o-rama GX2", "ZippyMobile", etc. Do not exist
Obviously.
Proof that this is only a solution to an imagined problem. If you put in a real life solution, like iOS user wanting to switch to Android the "app container" does nothing for you.
Now, if you continue to read that comment, you'll find the "real-life" example of users migrating from iOS to Android.
If you're referring to this:
"If you need me to take this as far as possible, consider the difficulty an Apple user with a sizable investment in apps and games considering an Android phone."
All you point out is the vendor lock in problem you think is such a big problem, so how does the "app container" solve that specific problem? Oh right, it doesn't.
Did you miss this gem: "it's very unlikely that Apple with support them."?
Right so your assertion that I "don't trust the promise of cross-platform apps" would be well founded. That promise is broken already as it doesn't work on the most common and best selling smartphone in the world, the iPhone.
Not internally, that's something that needs worked out.
How? What's your sell to Google and to developers? Google - the dominant player - gets a way for people to move away from its platform (the customers with ability to move to its platform comprise of less that 0.5% of the market) and developers get paid once for all platforms rather than once for each platform.
That they're automatically repackaged as part of the install process isn't relevant here at all.
Of course it is, how do I move from Android to Firefox OS and take everything with me? Even if my app were available on FirefoxOS what about all the application data? This "app container" fails to take that into account and that is a massive part of vendor lock-in.
As I've already pointed out, you can browse the market and run FXOS apps on Android. I'm pretty sure they're market share is greater than 1%.
And nobody does it and the default is Google Play with APKs. The fact that nobody wants to use it shows that nobody wants it, how much more proof do you need?
Wrong again. I used real things instead of made up ones,
Fun fact: So did I.
Rubbish. "Wizbang 3000", "SpiffyOS", "Neat-o-rama GX2", "ZippyMobile", etc. Do not exist, but I see why you needed to make them up because your example fails with real products.
If Linux can support proprietary drivers for graphics cards, any GPL software can support proprietary add-ins.
No. The Linux kernel is a special case and has a preamble to the GPL in its COPYING file to explicitly allow this:
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
As long as these add-ins don't require the recompilation of the host's sourcecode with proprietary code
So the GPL can be circumvented with dynamic linking?
I didn't realize Androids market share had shrunk to less than 1%... Oh, wait.
Android does not use this app package, you're completely delusional if you actually believe people are going to worry about whether their $2 impulse buy is going to be a safe long-term investment and then see if it is available on a 3rd party store on the chance that in future they may want to switch platforms and that future platform might then also support this app.
My answer hasn't changed. Anyone with a sizable investment in apps that wants to switch platforms. That's a lot of people. Before you say "specific" How about this: Specifically, any iOS user who wants to migrate to Android that faces either losing their collection of apps or repurchasing them on Android. I know two people who have this exact problem right now.
And you actually believe Apple will support this "standard app package"? You really genuinely believe that?
Does Mozilla have a viable offering? As I've pointed out countless times already, FXOS apps are supported on platforms other than FXOS.
Except it's not on any of the ones that matter, not on any of the ones used in 99%+ of the market.
You also asked me to show how a standard app package helps to solve this very problem. I've done that as well, though the example you mangled. It should be obvious to you that Bob would be well-served by a standard app package.
Wrong again. I used real things instead of made up ones, because your solution doesn't work in reality which is why you had to made up non-existent things like "WizBang 3000" and "WarpOS2".
You couldn't be more wrong on that point, as I've already explained. FXOS packages already enjoy support on other platforms.
Ok but not on 99+% of the platforms actual people use. Which is why I asked who - in the real world - has the problem that this solves?
The goal, of course, is to continue to increase the number of platforms that support the app package.
Well sort of, you can have it supported by 100 platforms but if 99+% of people don't use those platforms then it doesn't really help anybody. So you need to get it on iOS, Android and Windows Phone but if developers continue supporting those platforms in addition to the Mozilla standard then those vendors have even less reason to support it. See what I mean?
Did you miss the bit about migrating from iOS to Android?
No, but explain to me how a user that is "vendor-locked" to iOS can transition to Android thanks to this standard app container.
I've taken the liberty of converting your made up example into a real one so you understand the problem:
Alice wants to buy the new Apple iPhone mobile, but it runs iOS. Her current mobile, a Samsung Galaxy S5, runs Android. She has about $100 worth of apps and games that she doesn't want to lose.
What can Alice do? She can pass on the Apple iPhone and buy the new Samsung Galaxy S6. It isn't as cool, but she'll be able to keep all her apps and games. The Apple iPhone has all those apps and games, of course, but she'll need to buy them again for the new platform, essentially adding an extra $100 to the cost of her new mobile.
Substituted with real things rather than made up ones. This is the problem, yes? So how does Mozilla's "standard app container" help Alice?
Bob wants to buy the new Apple iPhone as well. He has a Lumia running Windows Phone. Bob also has about $100 worth of apps and games.
Fortunately, for Bob, most of his apps and games were purchased from Appermart, which distributes apps using a standard package.
Whoa...let me just stop you there. Bob can't do that, because Windows Phone doesn't support "Appermart". Even if Bob were running FirefoxOS he wouldn't be able to run his apps on his new iPhone or his new Galaxy or his new Windows Phone. In fact none of the operating systems that comprise 99% of the market support apps from "Appermart". So if you're in the 99% of smartphone users that use iOS, Android or Windows Phone or want to transition from FirefoxOS to any of these platforms then this doesn't solve your problem at all.
The question you should be asking isn't "where can I buy the Samsung Galaxy S6", but "is this something that happens in real life?" The answer is a resounding "yes".
Ok but given that in real life 99% of the market has iOS, Android or Windows Phone, how does this solve the problem?
Even if developers create HTML5 apps and target iOS, Android, Windows Phone and FirefoxOS that still doesn't solve the above problem, you still can't take your FirefoxOS apps and run them on iOS, Android or Windows Phone.
On 0: I don't need to prove vendor lock-in is a problem for the same reason I don't need to prove evolution happens. It's well-established already.
We know it exists, nobody is disputing that. Are you dense or can you not parse basic English? I said prove it is a problem that users have, but you fail again. You assume that because vendor lock-in is a thing that it must be a problem that everybody has everywhere, this is a false assumption.
All of these developers just wrap their apps in platform-specific containers for iOS, Android and Windows Phone
This is why I don't think you're being genuine. I made it perfectly clear that those developers are deploying their apps using the standard app package Mozilla has proposed, which already enjoys cross-platform support.
Well no, when they are deploying to iOS, Android and Windows Phone they are not using Mozilla's app package...those platforms do not support it, they are only using it to deploy to FirefoxOS.
I'll add to this: The ability to repackage apps does not offer the same benefits. The example I've used over and over again are new platforms struggling to attract developers.
That is not a problem for existing vendors, developers or users. It is only a problem for new platforms.
Which, of course, is silly nonsense. Things are moving faster than every before, and we're seeing unprecedented cooperation between vendors on these new standards.
Citation.
I've already given one example
False. It's pretty clear you are being disingenuous as you know very well that your example is a draft, it is not in the standard.
For most applications, on desktop and mobile, the existing standards and their implementations are already sufficient.
Wrong.
. Yet again the "standard app container" provides no benefit and isn't used.
This is, of course, completely false and you know it. It is being used by thousands of developers ranging from big name shops to individual hobbyists.
See now you aren't even reading and are quoting out of context. If you take it in context you see that this "standard app container" is only used on FirefoxOS hence is not used in 99.9% of real situations, making it virtually useless.
Alice wants to buy the new Wizbang 3000 mobile, but it runs SpiffyOS. Her current mobile, a Neat-o-rama GX2, runs ZippyMobile. She has about $100 worth of apps and games that she doesn't want to lose.
No, not a made up example. A real example, which you fail to do because your ideas are purely theoretical and so the only example you can come up with is a made up one. Try again.
A very common real-life example of vendor lock-in would be a sizable investment in iTunes.
iTunes is a desktop application, this is not targeted at desktop applications so you're wrong again.
See, you really are living in the past! While you've been stuck in 2005, the rest of the world has been busy developing and deploying cross-platform apps successfully in spite of weak standards with sketchy vendor support.
And by and large they do so using cross-platform tools that target native platforms because the WORA method doesn't work.
You simply don't trust the promise of cross-platform apps.
Because it has a proven track record of failure time and time again and every new promise still fails to address the failures of the last one. You are demonstrating that you can't learn from previous mistakes. You can't even provide a real example of the problem you are trying to solve, it's all just made up.
Why would the GPL license be a problem for corporate environments?
Unless you change the code and distribute the changed version outside your organisation, the license really doesn't matter much.
Can LibreOffice support proprietary add-ins? I'm not sure whether the GPL allows this.
Slashdot Mirror
The first sentence states it was Pixer's second open source project, so there is the suggestion...
Yes, a simple search will tell you their first one was OpenSubDiv.
the only difference between a file format and a standard is that with a standard multiple people agree to use the same file format.
That's nice but not really relevant since USD isn't a file format or a standard.
It does provide a (both binary and ascii) file format but it is much more than that, that alone isn't particularly useful. USD itself is a scenegraph format and provides c++ libraries and python bindings for modifying that graph. You also don't have to just use usda and usdb files, in theory you could write a plugin to support any kind of file format you like.
COLLADA is just a file format.
Does this software do something that the Blender devs currently can't do (and aren't making good progress on)?
This is about allowing different applications to inter-operate by having a common scene description format, it's nothing to do with free software.
(Note: Renderman is still proprietary, it just costs nothing for a non-commercial licence. Not free software at all.)
I don't think anybody implied it was Free Software, they released it free (as in the general interpretation: "without cost") for non-commercial use.
That they don't do that right now doesn't matter.
Well actually it does, they're going to find it hard to implement that tax dodge described here until they actually do it.
How long would you expect it to stay that way before profitable companies get their own IPOs?
How long is a piece of string? I'm not going to speculate on the many different things that may or may not happen in various scenarios. Just that what you speculated here is not what is happening given the way the new organisation has been structured.
There are two independent sets of developers, the graphic driver developers and the developers who actually use the API.
And the OpenGL extension methodology serves both. Developers can utilize the new features of new GPUs when they know what they are targeting and developers targeting broader audiences use core profiles.
The graphic developers may love that they can extend OpenGL to make use of their random new fangled features in their graphics card
That's good, you don't want to have to wait until a new feature is incorporated into the standard before you can use it.
but the developers actually using the API now need to check for some huge number of custom extensions that may or may not exist.
No they don't, that's what the core profile is for. If you want to target a broad audience then use that.
The whole draw of OpenGL was that developers could just add in the effects they wanted and allow users to turn them on/off to improve looks/performance. You weren't reliant upon the static/unflexible capabilities of APIs like D3D.
Except that the world changed and most of the "effects" shifted away from the underlying fixed function pipeline and into the programmable hardware which removed the inflexibility.
Now they're just playing the copycat game, and ignoring their biggest strength, to truly push GPU hardware to the limit.
This is about pushing GPU hardware to the limit, they are removing the generic resource management implementations that reside in the driver and force applications to suffer significant overhead by being unoptimized (hence the reason drivers are so large and that driver releases often include optimizations for AAA titles). The GPU resources are now under the direct control and management of the application which can take full advantage of the GPU rather than relying on the generic driver implementations.
Not so sure about that, it could become like Berkshire Hathaway where a single company controls multiple companies, each with their own publicly traded stock
Except that it couldn't be clearer:
"Alphabet Inc. will replace Google Inc. as the publicly-traded entity and all shares of Google will automatically convert into the same number of shares of Alphabet, with all of the same rights. Google will become a wholly-owned subsidiary of Alphabet."
From the blog post
Which is exactly what Spy Handler said.
Is the home button the little triangle, circle or square?
http://files.tested.com/photos...
If you're struggling at this point you should probably just put it down and forget about it.
I want a micro-tablet. I want a cell phone without the phone to hold my shopping list, music, and podcasts. I don't want the phone.
Why doe this not exist?
It does. But most devices include the phone anyway because the cost is trivial and it's not worth it to create the tooling and manufacturing to produce a separate product which is basically the same thing without the phone.
Win + Break gets you to the link for 'Advanced system settings'. Works in at least win7, 8, 8.1, 10.
Ha! So it does. Thanks.
So, because it's not going to work everywhere, it has no value?
No, it fails in its mission of being cross-platform when it doesn't support the most popular smartphone in the world and indeed the platform of one of the biggest content providers.
Just because it's not helpful to iOS users doesn't mean it's useless to everyone.
But the only thing you have given me that is even close to a real life example is of iOS users trying to migrate to Android.
I expect that we'll see better integration not from Google directly, at least not initially
Ok so you have no sell to Google, the MAJOR platform vendor and you have no sell to Apple the other major platform vendor...not a good start.
Amazon would be an example of such a vendor as it clearly benefits them.
Amazon is a TERRIBLE example, they benefit from selling you apps, if you can move to their platform without buying your apps from them that's pointless to them.
Again, for developers, the advantage is an expanded market
Rubbish, your key selling point for this is so that people can move platforms without buying their apps again, a net loss to developers. Targeting other platforms is trivial, it's a problem nobody has, as you pointed out already it's so trivial you can wrap it in the installer for Android.
Revenues from repurchased apps are signal noise.
Citation? I'll bet this is yet another thing you haven't done your research on though.
Transitioning from one platform to another while keeping your data is no different than transitioning between devices that use the same platform. Locally stored data merely needs copied.
And where on the local storage is the app data stored exactly? Tell me exactly what I need to copy from Android - and where - to Firefox - and where. You're overlooking the important details that cause these things to fail.
how much more proof do you need?
Proof of what? I still have absolutely no idea what you're trying to accomplish.
That people don't want it. It's there and people aren't using it. And you are still begging me to give you some validation that users want it.
Rubbish. "Wizbang 3000", "SpiffyOS", "Neat-o-rama GX2", "ZippyMobile", etc. Do not exist
Obviously.
Proof that this is only a solution to an imagined problem. If you put in a real life solution, like iOS user wanting to switch to Android the "app container" does nothing for you.
Now, if you continue to read that comment, you'll find the "real-life" example of users migrating from iOS to Android.
If you're referring to this:
"If you need me to take this as far as possible, consider the difficulty an Apple user with a sizable investment in apps and games considering an Android phone."
All you point out is the vendor lock in problem you think is such a big problem, so how does the "app container" solve that specific problem? Oh right, it doesn't.
Did you miss this gem: "it's very unlikely that Apple with support them."?
Right so your assertion that I "don't trust the promise of cross-platform apps" would be well founded. That promise is broken already as it doesn't work on the most common and best selling smartphone in the world, the iPhone.
Not internally, that's something that needs worked out.
How? What's your sell to Google and to developers? Google - the dominant player - gets a way for people to move away from its platform (the customers with ability to move to its platform comprise of less that 0.5% of the market) and developers get paid once for all platforms rather than once for each platform.
That they're automatically repackaged as part of the install process isn't relevant here at all.
Of course it is, how do I move from Android to Firefox OS and take everything with me? Even if my app were available on FirefoxOS what about all the application data? This "app container" fails to take that into account and that is a massive part of vendor lock-in.
As I've already pointed out, you can browse the market and run FXOS apps on Android. I'm pretty sure they're market share is greater than 1%.
And nobody does it and the default is Google Play with APKs. The fact that nobody wants to use it shows that nobody wants it, how much more proof do you need?
Wrong again. I used real things instead of made up ones,
Fun fact: So did I.
Rubbish. "Wizbang 3000", "SpiffyOS", "Neat-o-rama GX2", "ZippyMobile", etc. Do not exist, but I see why you needed to make them up because your example fails with real products.
If Linux can support proprietary drivers for graphics cards, any GPL software can support proprietary add-ins.
No. The Linux kernel is a special case and has a preamble to the GPL in its COPYING file to explicitly allow this:
NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".
As long as these add-ins don't require the recompilation of the host's sourcecode with proprietary code
So the GPL can be circumvented with dynamic linking?
I didn't realize Androids market share had shrunk to less than 1%... Oh, wait.
Android does not use this app package, you're completely delusional if you actually believe people are going to worry about whether their $2 impulse buy is going to be a safe long-term investment and then see if it is available on a 3rd party store on the chance that in future they may want to switch platforms and that future platform might then also support this app.
My answer hasn't changed. Anyone with a sizable investment in apps that wants to switch platforms. That's a lot of people. Before you say "specific" How about this: Specifically, any iOS user who wants to migrate to Android that faces either losing their collection of apps or repurchasing them on Android. I know two people who have this exact problem right now.
And you actually believe Apple will support this "standard app package"? You really genuinely believe that?
Does Mozilla have a viable offering? As I've pointed out countless times already, FXOS apps are supported on platforms other than FXOS.
Except it's not on any of the ones that matter, not on any of the ones used in 99%+ of the market.
You also asked me to show how a standard app package helps to solve this very problem. I've done that as well, though the example you mangled. It should be obvious to you that Bob would be well-served by a standard app package.
Wrong again. I used real things instead of made up ones, because your solution doesn't work in reality which is why you had to made up non-existent things like "WizBang 3000" and "WarpOS2".
You couldn't be more wrong on that point, as I've already explained. FXOS packages already enjoy support on other platforms.
Ok but not on 99+% of the platforms actual people use. Which is why I asked who - in the real world - has the problem that this solves?
The goal, of course, is to continue to increase the number of platforms that support the app package.
Well sort of, you can have it supported by 100 platforms but if 99+% of people don't use those platforms then it doesn't really help anybody. So you need to get it on iOS, Android and Windows Phone but if developers continue supporting those platforms in addition to the Mozilla standard then those vendors have even less reason to support it. See what I mean?
Did you miss the bit about migrating from iOS to Android?
No, but explain to me how a user that is "vendor-locked" to iOS can transition to Android thanks to this standard app container.
Alice wants to buy the new Apple iPhone mobile, but it runs iOS. Her current mobile, a Samsung Galaxy S5, runs Android. She has about $100 worth of apps and games that she doesn't want to lose.
What can Alice do? She can pass on the Apple iPhone and buy the new Samsung Galaxy S6. It isn't as cool, but she'll be able to keep all her apps and games. The Apple iPhone has all those apps and games, of course, but she'll need to buy them again for the new platform, essentially adding an extra $100 to the cost of her new mobile.
Substituted with real things rather than made up ones. This is the problem, yes? So how does Mozilla's "standard app container" help Alice?
Bob wants to buy the new Apple iPhone as well. He has a Lumia running Windows Phone. Bob also has about $100 worth of apps and games.
Fortunately, for Bob, most of his apps and games were purchased from Appermart, which distributes apps using a standard package.
Whoa...let me just stop you there. Bob can't do that, because Windows Phone doesn't support "Appermart". Even if Bob were running FirefoxOS he wouldn't be able to run his apps on his new iPhone or his new Galaxy or his new Windows Phone. In fact none of the operating systems that comprise 99% of the market support apps from "Appermart". So if you're in the 99% of smartphone users that use iOS, Android or Windows Phone or want to transition from FirefoxOS to any of these platforms then this doesn't solve your problem at all.
The question you should be asking isn't "where can I buy the Samsung Galaxy S6", but "is this something that happens in real life?" The answer is a resounding "yes".
Ok but given that in real life 99% of the market has iOS, Android or Windows Phone, how does this solve the problem?
Even if developers create HTML5 apps and target iOS, Android, Windows Phone and FirefoxOS that still doesn't solve the above problem, you still can't take your FirefoxOS apps and run them on iOS, Android or Windows Phone.
As long as you don't distribute them outside the organization, GPL shouldn't care -- GPL is all about distribution.
A lot of the organizations that make addins do generally want to distribute them to companies to use them.
On 0: I don't need to prove vendor lock-in is a problem for the same reason I don't need to prove evolution happens. It's well-established already.
We know it exists, nobody is disputing that. Are you dense or can you not parse basic English? I said prove it is a problem that users have, but you fail again. You assume that because vendor lock-in is a thing that it must be a problem that everybody has everywhere, this is a false assumption.
All of these developers just wrap their apps in platform-specific containers for iOS, Android and Windows Phone
This is why I don't think you're being genuine. I made it perfectly clear that those developers are deploying their apps using the standard app package Mozilla has proposed, which already enjoys cross-platform support.
Well no, when they are deploying to iOS, Android and Windows Phone they are not using Mozilla's app package...those platforms do not support it, they are only using it to deploy to FirefoxOS.
I'll add to this: The ability to repackage apps does not offer the same benefits. The example I've used over and over again are new platforms struggling to attract developers.
That is not a problem for existing vendors, developers or users. It is only a problem for new platforms.
Which, of course, is silly nonsense. Things are moving faster than every before, and we're seeing unprecedented cooperation between vendors on these new standards.
Citation.
I've already given one example
False. It's pretty clear you are being disingenuous as you know very well that your example is a draft, it is not in the standard.
For most applications, on desktop and mobile, the existing standards and their implementations are already sufficient.
Wrong.
. Yet again the "standard app container" provides no benefit and isn't used.
This is, of course, completely false and you know it. It is being used by thousands of developers ranging from big name shops to individual hobbyists.
See now you aren't even reading and are quoting out of context. If you take it in context you see that this "standard app container" is only used on FirefoxOS hence is not used in 99.9% of real situations, making it virtually useless.
Alice wants to buy the new Wizbang 3000 mobile, but it runs SpiffyOS. Her current mobile, a Neat-o-rama GX2, runs ZippyMobile. She has about $100 worth of apps and games that she doesn't want to lose.
No, not a made up example. A real example, which you fail to do because your ideas are purely theoretical and so the only example you can come up with is a made up one. Try again.
A very common real-life example of vendor lock-in would be a sizable investment in iTunes.
iTunes is a desktop application, this is not targeted at desktop applications so you're wrong again.
See, you really are living in the past! While you've been stuck in 2005, the rest of the world has been busy developing and deploying cross-platform apps successfully in spite of weak standards with sketchy vendor support.
And by and large they do so using cross-platform tools that target native platforms because the WORA method doesn't work.
You simply don't trust the promise of cross-platform apps.
Because it has a proven track record of failure time and time again and every new promise still fails to address the failures of the last one. You are demonstrating that you can't learn from previous mistakes. You can't even provide a real example of the problem you are trying to solve, it's all just made up.
Well that's good then.
Why would the GPL license be a problem for corporate environments? Unless you change the code and distribute the changed version outside your organisation, the license really doesn't matter much.
Can LibreOffice support proprietary add-ins? I'm not sure whether the GPL allows this.