I'm not sure if it's Ars' commentary, or just the commenters, but it seems entirely sided towards Microsoft. Ars didn't mention that Microsoft didn't want to play by the rather simple rules of "put the video in a web frame", and that Microsoft admits to re-releasing the application they previously pulled because it didn't follow the rules.
Plus, it seems like the author of the post fails to understand what Google wanted, and that Microsoft was being totally passive-aggressive in their blog post.
>Ars didn't mention that Microsoft didn't want to play by the rather simple rules of "put the video in a web frame", and that Microsoft admits to re-releasing the application they previously pulled because it didn't follow the rules.
What are you talking about? It says that in the article right here:
>First, the advertising giant is demanding specifically that Microsoft rewrite the application to use HTML5. Microsoft doesn't elaborate on why Google has made this demand but points out that Google's own apps on iOS and Android do not use HTML5. The software company claims that this is a "manufactured" reason, invented only to ensure that the YouTube experience on Windows Phone is inferior to that on iOS and Android.
I agree that using an iframe is going to suck compared to directly playing the video. Do you disagree?
It's a 'simple' demand sure, but it's pointless, inconsistent with other platforms, and lowers quality.
Edit: Ugh, why is your comment still at the top when it is factually incorrect? Am I weird for compulsively downvoting factually incorrect comments?
The simple reason for requiring them to embed it using HTML5 is that then YouTube can control the presentation, including advertisements. Otherwise they would have to constantly work with Microsoft to have them update their native code when they make changes.
It's the same reason Twitter has these guidelines for how you can display tweets.
I don't agree that an iframe would suck compared to directly playing the video.
If Microsoft can't write a browser with an acceptable video tag, it's their own fault, not an API provider's fault.
Mozilla, Apple, and Google all seem to have been able to create browsers with good video tags, especially Apple and Google, who have great support on their mobile systems, which implies that Microsoft should be able to either write their own, or copy the Webkit or Gecko implementation.
It's not inconsistent with other platforms, because anyone who isn't Google is required to follow the same rules as Microsoft. The only difference between Android/iOS and Windows Phone in this instance is that Google isn't going to build a WP app. When they're making the application, they know when they're going to make a change to the entire system, nobody else does, unless they publicize it, and nobody has an incentive to make the switch unless Google is willing to be more proactive about making sure everyone follows more rules.
How does requiring one component, the video, lower quality? If Microsoft doesn't have a web view for WP, and requires applications to be entirely native or entirely web-based, how is that Google fault?
If Google let anyone use the same system they use for their own YouTube app, they'd have to have a grace period where applications could use the old system before updating to the new system, and they'd have to be proactive about making sure everyone uses the new system after their deadline. That's a whole lot more work than saying "follow our really simple rule of using a web view".
Google has every right to make their demand. Google has every right to enforce their rules. Google has every right to ignore their own rules. They have a good reason to have the video tag rule. If they weren't the ones actively developing YouTube, and the Android and iOS apps, they'd probably agree to following the video tag rule, because it makes sense.
----
As for your quote from the article, it doesn't say Microsoft re-released their application after agreeing to follow the rules. It doesn't mention that they're not willing the follow the rules. It just says they didn't follow the rules because they didn't like them.
There are several iOS and Android apps for YouTube that aren't the official app. They all seem to be able to follow Google's rules, and don't seem to be doing poorly.
It may be worth noting that the author, Peter Bright, is the Microsoft editor for Ars. He also happens to have a strong anti-google bias - I can't remember any pieces he's written that portrayed Google in a favorable light.
This whole thing is a giant nothingburger. There are plenty of Youtube apps for WP. The official one on iOS that got so much hype on release (and talk now regarding the lack of a WP version) is frankly awful compared to many of the alternatives and currently sits at 2 stars on the iOS store.
WP users be thankful you don't have either the MS port or an official Google one. From what I gather even if you had both, you'd still want to download Metrotube.
"At Google we believe that open systems win. They lead to more innovation, value, and freedom of choice for consumers, and a vibrant, profitable, and competitive ecosystem for businesses. Many companies will claim roughly the same thing since they know that declaring themselves to be open is both good for their brand and completely without risk. After all, in our industry there is no clear definition of what open really means. It is a Rashomon-like term: highly subjective and vitally important."
..
"To understand our position in more detail, it helps to start with the assertion that open systems win. This is counter-intuitive to the traditionally trained MBA who is taught to generate a sustainable competitive advantage by creating a closed system, making it popular, then milking it through the product life cycle. The conventional wisdom goes that companies should lock in customers to lock out competitors."
...
"To understand our position in more detail, it helps to start with the assertion that open systems win. This is counter-intuitive to the traditionally trained MBA who is taught to generate a sustainable competitive advantage by creating a closed system, making it popular, then milking it through the product life cycle. The conventional wisdom goes that companies should lock in customers to lock out competitors. There are different tactical approaches — razor companies make the razor cheap and the blades expensive, while the old IBM made the mainframes expensive and the software ... expensive too. Either way, a well-managed closed system can deliver plenty of profits. They can also deliver well-designed products in the short run — the iPod and iPhone being the obvious examples — but eventually innovation in a closed system tends towards being incremental at best (is a four blade razor really that much better than a three blade one?) because the whole point is to preserve the status quo. Complacency is the hallmark of any closed system. If you don't have to work that hard to keep your customers, you won't."
...
"In other words, Google's future depends on the Internet staying an open system, and our advocacy of open will grow the web for everyone - including Google."
I'm all in agreement on the hypocrisy of Google's "open" bullshit train but isn't the central issue here that the gd brand mark for YouTube is simply not free to use?
I think Google is within their rights to put whatever limits they want in that area, even unreasonable ones.
And while 2/3 of HN is happy to swallow the open kool aid, last I checked MS wore big boy pants and surely they can do better than crying about their big unfair rival on their blog.
I agree with this comment on the Ars thread[1]. I know this was discussed extensively here[2]. But, the comments on the thread seemed a bit biased towards one side.
With that logic, Google could block any other phone like the Ubuntu Edge for "business reasons", Google deserves to be sued for this anti-competitive behavior.
its not anticompetitive to not allow a third party to release your product on their platform without following your rules (reasonable or not).
Hundreds of millions of dollars in engineering effort and bandwidth go into Youtube. In reality Google is completely within its rights to no do anything to support any platform it chooses not to. Why allow a platform and company to leech off that if they're not willing to. Microsoft is just trying to win in the court of public opinion here.
Can't you use that exact same logic to argue that Comcast has spent billions of dollars laying cable into the ground and that it's completely reasonable for them to not allow content that doesn't fit within the goals of their "platform" like netflix traffic?
That comparison seems weird because the relationships aren't the same. Comcast's customers are the people who pay for Comcast service at their homes and businesses. If Comcast favors its own content over other content, and they have a local monopoly on internet service, then they are using their monopoly to abuse their customers.
Neither Microsoft, nor owners of Windows Phone handsets, are customers of YouTube. The only people who are customers of YouTube are people who pay to have their videos hosted there.
Is YouTube purporting to provide me with Internet access or otherwise operate as infrastructure? I must have missed that.
If Comcast wants to provide a digital network that provides connectivity between selected entities (such as end-users and companies that have elected to pay Comcast additional fees), that's fine. But they don't get to call it "Internet". They don't get to pass it off as something different from the AOL and CompuServe of old.
Comcast and many cable ISPs have a monopoly for high speed Internet in many parts if the US. YouTube is not forced on anyone due to where they live, and there are plenty of alternatives to YouTube out there that you are free to use.
That would be OK is the rules weren't arbitrary, it is not OK to allow native API calls to some and to force to use HTML5 to others, it is inexcusable.
There are no "others" and no "rules". Google makes the iOS and Android apps, not third parties. The Windows Phone YouTube app would be the first significant (1) phone OS to have a YouTube app not made by Google, there are no others to compare Google's behavior on for fairness. This is the first event of its kind.
(1) If you consider single digits market share to be significant.
Actually, there are phone YouTube apps not made by Google, such as Jasmine for iOS, as has been brought up repeatedly. Unlike Microsoft, they complied with the rules, rather than throw a hissy fit.
The rules are arbitrary if Google doesn't abide by them when making publishing its own versions of YouTube apps on the dominant platforms. It's behavior is anti-competitive if it uses its position as gatekeeper to YouTube to stifle Windows Phone by placing requirements on Microsoft that it doesn't place on itself.
The rule exists to ensure the continued compatibility of third-party applications with requirements of the YouTube service. Google can fix its own apps, and it can fix the content of an iframe loaded from its servers, but it can't fix apps it doesn't control.
There are good reasons for this very simple rule that everyone but Microsoft seems able to comply with. By definition, such a rule cannot be "arbitrary".
It's disingenuous to say "everybody but Microsoft" when the group size of third-party apps that act as realistic YouTube viewers is something like 2-4.
If you pride yourself and market yourself on openness any rule that flies in the face of said openness is entirely arbitrary, because there shouldn't be any rules limiting your openness.
It's disingenuous to treat your religious dogma on the word "open" as shared by everyone else. I don't believe for a second you understand how Google is using the term nor what they are applying it to.
>The Windows Phone YouTube app would be the first significant (1) phone OS to have a YouTube app not made by Google, there are no others to compare Google's behavior on for fairness. This is the first event of its kind.
It's also the only significant phone OS that doesn't ship with Google search as the default.
How is this any different than me releasing my code under something like the LGPL, which would allow those folks who dynamically link to not release source to their app, but force those who are required to statically link (due to platform or other reasons) to release source to their app?
Note that it's a similar situation. If I release code under the LGPL, i don't have to abide by it, only others do.
Twitter requires third party API users limit themselves to 100k users (or whatever it is), but, even though they use the same API, does not require it of itself.
They also have decided some folks don't have to abide by this.
How is this different?
None of this is "anti-competitive" behavior.
Would you think it anti-competitive behavior if Google provided no API and also told people finding ways to embed it to stop?
It's anticompetitive because Google is using its dominant online video platform to promote its mobile OS, even though those are really two separate industries. It's no different from MS selling an internet server that uses nonstandard extensions and only making those available on windows.
HTML5 seems to be the only public API they expose, and obviously they don't want random apps to depend on other, possibly undocumented APIs intended for internal use. Google can use any kind of whatever internal API they have in place in their own apps, I don't see why they should follow their own third party usage guidelines.
>its not anticompetitive to not allow a third party to release your product on their platform without following your rules (reasonable or not).
That is actually the definition of being anti-competitive. Google is gaining an unfair advantage w.r.t. Android vs WP by manipulating terms of their extremely popular video service to make it not work on their competitors product.
Exactly, Microsoft already does something similar by reserving some of their APIs for their own use. There are others that are available to some (eg the carriers) but nobody else.
It's nothing new, they have had so-called 'private' APIs since the early days of Windows.
And Windows detected DR-DOS and crashed your computer to kill DR-DOS and MS paid a paltry $150M to Caldera later but they got to upkeep their monopoly in the PC market. Now they get a small serving of this medicine and it's far less sinister and they whine. Oh they irony.
>And Windows detected DR-DOS and crashed your computer to kill DR-DOS and MS paid a paltry $150M to Caldera later but they got to upkeep their monopoly in the PC market.
Actually Windows ran perfectly fine over DR-DOS. Perhaps you're thinking of the beta version which included the code to not allow Windows to run on any dos other than MS-DOS. The reason obviously is purely technical. Because of the way Windows 3.1 worked it required access to internal MS-DOS undocumented data structures which could not be guaranteed to work on any other DOS clone.
In fact Windows crashed on MS-DOS 4.0 because the internal data structures changed. MS-DOS 4.0 contains special code for backwards compatibility to trick Windows into thinking its running on the older version.
> Microsoft also debated the exact language the message should contain. In the end, senior vice president Brad Silverberg said in a 1992 email that the message needed to steer users away from DR-DOS. "What the [user] is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is DR-DOS and then go out to buy MS-DOS," Silverberg wrote.
>It's nothing new, they have had so-called 'private' APIs since the early days of Windows
Point to a single "private" API. There is no such thing. Preemptive apologies if you're a non technical person as these things are obvious to most programmers so I don't really want to berate anyone for simply not having sufficient information.
For recent examples I was thinking specifically about the Windows.Networking.NetworkOperators APIs and such. These APIs are 'private' to network operators. If you try to use them from a regular app then you'll be kicked out of the store.
Or search msdn for "This API is not intended to be used directly from your code" for examples of other APIs that are 'private' to Microsoft and will similarly get you booted.
Going back in time, there were (still are) a great many dlls and services in Windows with unnamed exports and not available to the general public (eg win32k, csrss, milcore etc).
Go back to the dark ages and as others have already mentioned there's the famous AARD example that used undocumented DOS data structures to distinguish MS-DOS from other variants.
>If you try to use them from a regular app then you'll be kicked out of the store.
Um.. That is not a private API. Those are the terms of the STORE, not the OS. You can use the API from whatever app you want. Although as a programmer I personally dislike such restrictions, its no different from what Google or Apple are doing for their own stores.
>Going back in time, there were (still are) a great many dlls and services in Windows with unnamed exports and not available to the general public (eg win32k, csrss, milcore etc)
What the... What are you talking about? Those DLLs are internal OS DLLs. Nobody besides OS components has any use for those APIs.
>Go back to the dark ages and as others have already mentioned there's the famous AARD example
Which never shipped since it was part of a windows beta version.
>Like I said, nothing new.
You can say anything you want ofcource. You'll have to bring actual evidence if you want to be taken seriously though.
That's why I put 'private' in quotes. Given a decent debugger, nothing is strictly private but then it's a meaningless distinction. Perhaps there's a better term for APIs you can technically call but will get your app kicked out of the store for TOS violation? I think 'private' makes sense but I'm happy to use whatever term you think is reasonable.
As for 'internal OS DLLs' I think it's subjective as to whether those APIs have any use outside of OS components (and indeed what constitutes an 'OS component'). I happen to think there's some really useful stuff in there. Anyway, I only brought it up to highlight that there are some things Microsoft has decided we can't use for whatever reason. Again, I think it's reasonable to consider them 'private', non-public, internal. I'm not saying any of this is good\bad or that they shouldn't have the right to do this sort of thing. Just that it exists.
As for AARD, technically it did 'ship' as the code was included in Win3.1 but was benign thanks to a runtime flag. Even in beta form it highlights that this sort of thing, relying on undocumented behavior, has been used at Microsoft for a very long time. Perhaps it's an insignificant example but it did cost them close to $300M in a settlement so seemed pretty relevant to me.
Anyway, I shall leave it to other readers to decide if any of this constitutes evidence of so-called private APIs by Microsoft.
>Perhaps there's a better term for APIs you can technically call but will get your app kicked out of the store for TOS violation?
So, first you make a claim about "since the early days of windows" OS APIs useful to others have been hidden that apparently only MS applications get to use. Yet you have failed to point out a single shipping microsoft application that benefited from those APIs or even actually mentioned what those APIs are or what they do. And now you're talking about some fringe windows 8 RT app store restrictions. Windows history spans from 1985 to 2013. Surely you should have hundreds of thousands of examples that you can google?
> Anyway, I only brought it up to highlight that there are some things Microsoft has decided we can't use for whatever reason.
Sorry. I still have no clue what are you talking about. Internal OS DLLs contain the implementation of the OS itself. Applications run on TOP of the OS. They don't re-invent what the OS already does.
I strongly suspect you're attempting to construct a non-technical argument about a purely technical topic. Anyway, I doubt you're going to present any evidence.. So, goodbye.
Do the proprietor's of those platforms want an "official" app that they are willing to put their own resources into developing? Remember, this is about Google cutting off an API key so Google isn't out any engineering/time/money resources, the "official" modifier is mostly marketing BS.
FirefoxOS doesn't need a native or official YouTube app, because the entire thing is just web pages. If Google wanted to make something official, all they would need to do is add an app manifest file with some metadata about the app.
Plus, it seems like the author of the post fails to understand what Google wanted, and that Microsoft was being totally passive-aggressive in their blog post.