Unfortunately I don't think the act as written would apply to iMessage. Seems like section 4e:
> Exemption for certain services.—The obligations under this section shall not apply to a product or service by which a large communications platform provider does not generate any income or other compensation, directly or indirectly, from collecting, using, or sharing user data.
would cut iMessage (and any other Apple service) out. I guess the argument could be made that Apple indirectly generates income from collecting data and making it available across their devices as a form of vendor lock-in, but that's shaky.
They absolutely are. Apple makes money from the iOS ecosystem in two ways: through device sales, and through App Store purchases.
I'd agree that iOS is an example of a restrictive platform, in that ~30% of all revenue goes to a single gate-keeping party.
In any case, I messed up the quote a little, another commenter found the source and real comment: 'Gates said something along the lines of, “That’s a crock of shit. This isn’t a platform. A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform.”' [1]
There's a great quote from someone whose name escapes me right now, about the definition of a platform being when revenue generated by software running on the device far outpaces revenue generated by sales of the device itself. I've always liked that definition, and it seems accurate to me based on historical evidence (PCs - definitely a platform. Smartwatches - definitely not).
In this test, the airpods fail abysmally - not only do they not allow for revenue generation today, they don't even allow for third party developers to use their hardware features in any capacity. In fact, the main use-case for airpods appears to be efficiency and convenience when combined with Siri. All three "sources" described by the article fail to define for me the benefit users will gain from airpods as a platform, and instead have done an excellent job of convincing me that users will benefit far more from treating airpods as a product.
Compounding this is the fact that most computing platforms are primarily visual in their interactions with their users - this is clearly no coincidence. Visual interfaces allow developers to surface many pieces of information at once, and they allow users to absorb information at a pace that is variable (based on context) and comfortable to them. Aural platforms don't have this capability, and the context that they assume is often wrong. For example, I've been driving a lot these past few days, and one of the worst Apple-built experiences I've ever had occurred when I needed to stop for gas. Not only was I directed to a gas station I had already passed (driving on the freeway), but when I wanted to navigate to another gas station there was no way (obvious or not) for me to tell Siri to find me a gas station ahead of me. In fact, there was no way to confirm where any of the gas stations Siri found me were in relation to me, without looking at my screen.
One more thing: Aural platforms are exclusively serial. They surface one piece of information at a time, and in fact they would be less usable if they surfaced any more than that (or surfaced each piece of information any quicker). This alone, I feel, makes them unsuitable platforms in today's world.
Edit: randall found the quote, by Bill Gates: 'Gates said something along the lines of, “That’s a crock of shit. This isn’t a platform. A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform.”' [1]
Interesting - if you don't mind indulging me a little, it was surprising to me that you chose kubernetes as the first implementation for this standard. After all, if a large part of OAM's functionality is provided by k8s out of the box (auto-scaling, for example) it's not very useful to someone who knows the existing tech. Kubernetes is, by and large, already portable with minimal dev resources between the major cloud vendors and/or on-prem resources.
On the other hand, if you can pair already-written software with a collection of VMs and place an OAM layer between the machines and business logic, the portability of your code between OAM-compatible vendors becomes a selling point for the standard. I know a large project like this is a team effort, but can you shed any light on the reasons behind your decision-making and prioritization towards kubernetes?
Dapr looks like Microsoft's answer to Istio - anecdotally, I've never gotten Istio to work (as recently as a few months ago) so I'll have to give this one a try at some point to see if they've done a better job.
OAM though, perplexes me. Even the justification - that k8s is out of scope of the developer, and is handled by ops - speaks to a misunderstanding of some of the advantages clusters provide. Some research [1] tells me that developers author "components" which encapsulate singular parts of an architecture, and are connected by operators into an application. And then auto-scaling is handled by "traits", which are entirely separate? It's interesting, but it seems to largely replicate (and act as a translation layer for) existing k8s features. Maybe that's the real value prop here, and the techcrunch article buried the lede - by defining components and traits through OAM you can move to any cloud-based model that supports the manifest spec (thus avoiding the high learning curve of something like k8s). Even so, I have a sinking feeling that most of this will be folded into the ever-changing definition of devops, so small teams that manage an app's entire lifecycle (and are told to get on board with the new-fangled dealio by management) will have another layer of indirection to debug when something inevitably goes wrong. If Azure comes out with an implementation of OAM that uses their VSIs, I'll get interested. Then it'll at least provide real value/choice, and hopefully make it easier to migrate existing workloads that don't need an entire machine for themselves onto a k8s cluster.
I've actually had the opposite experience - it was easy enough to download/set up, and then it was just a matter of getting the letsencrypt daemon on the box to manage certs.
That said, I went in with pretty low expectations since it's a reference implementation - I think one of the great advantages of the open-source protocol is that anyone can design/build their own implementations with better UX on the sysadmin side. There are already projects in the works written in golang/rust, and I'm sure if the protocol takes off other languages will follow.
I do agree that the identity server piece is weird. I didn't set one of these up, so I haven't really looked into it (I don't have any 3rd party IDs connected to my matrix username, which from my cursory research is what the identity servers are for) but the philosophy behind them seems to go against the federation narrative the rest of the protocol is designed around. If anyone has done more research into this part of the protocol I'd love to be corrected on this point.
Agreed on the point of the experiment, but I can only influence my own behavior :)
You'll notice that I'm only deleting the score node, and leaving the number of comments, post age, and author intact. Those add considerable value to my HN browsing, and allow me to avoid visiting the comment section or clicking a link that I'll gain marginal (or negative) value from.
In fact, I've always thought of HN (and other link aggregators) as a hub for discussion more than a collection of interesting links - the links themselves are often biased and it's important to learn about multiple sides of the topic lest the bias rubs off on me.
I figured I'd share to lower the bar for those who wanted to see the effects for themselves - anecdotally, it hasn't changed much for me since the points themselves are less important than the way they affect the algorithm. I generally don't post/comment, and rarely vote, so I'm not really concerned about my karma total. Maybe I'm not the target market for this experiment?
> Exemption for certain services.—The obligations under this section shall not apply to a product or service by which a large communications platform provider does not generate any income or other compensation, directly or indirectly, from collecting, using, or sharing user data.
would cut iMessage (and any other Apple service) out. I guess the argument could be made that Apple indirectly generates income from collecting data and making it available across their devices as a form of vendor lock-in, but that's shaky.