Apparently blaming the victim is totally okay as long as the victim was using a brand you don't like.
Two, calling this victim blaming is a bit of a stretch at best and ridiculous nonsense at worst. Yes, what happened to OP is unfortunate but it's just a moderate inconvenience. It's not like someone drove their car over him or smashed his face in with a bat (he'll get over this much easier). The person you replied to therefore is not wishing serious ill will on him. They are simply saying they hope this mild inconvenience is enough to wake him (and others) up to the necessity of free software.
> is enough to wake him (and others) up to the necessity of free software. What free software was he and everyone he's communicated with in the past 5 years supposed to be aware of?
I call BS. If OP choose free software we could AS WELL have had the same exact problem.
It's a software bug -- the client caching the remote method to use (data or standard SMS). A free program could just as well have the same issue.
What "more control" you'd have? You could issue a bug fix request, which could just as well be ignored (I've several on FOSS projets). Or you could even have it fixed, but then you'd need to convince all the users you talk to to update to the latest version until you see any improvement.
The difference here is that a sufficiently competent person cannot reliably replicate the experience.
Ugh, thinking like this just may well be the biggest problem in our industry.
Stop being user-hostile.
There's incentives for people who make closed systems to make the most common edges of them comfortable. There's also incentives for them to ignore other sharp edges or to even actively make other edges nearly untraversable.
Federation is a problem because none of the standards interop. The closest thing we had was XMPP which became mega-bloatware as time went by and is now just not something anyone wants to implement (and it's becoming less of an issue as most of the players move away from open-ness).
While the technical among us understand the ramifications of these decisions, the silent majority do not. I believe it was Elad Gil who said that services that eschew privacy have historically dominated their more private opponents. Users say they care about privacy but their explicit value systems (what they say versus what they do) says otherwise. The majority of consumers are happy to take iMessage and use it to the extreme and will attribute silent failures to the operators in most cases (which is not necessarily wrong).
True federated identity is the death of the phone network and there are just too many billions of dollars tied up in the world for this to come to pass. A phone number is a ridiculously arbitrary identifier for a person, and yet it works and has worked for quite some time. Logically addressed networks are finally starting to break, and that's a good thing, but the catalyst that will move us away from these systems is one that subsumes existing infrastructure while adding new features. You cannot rip and replace our communications networks (or any infrastructure for that matter) and so the only logical solution is to subsume. It's not easy, but that's how this gets fixed.
We got number portability and wireless number portability, but the carriers still act as if they own our e.164 addresses and make the transfers arbitrarily difficult. We use phone numbers of SMS, but really we use individual address books, stored in devices, or synchronized with central repositories. We use names to identify people and have to work hard to ensure that our address books are not filled up with duplicates created because we used a one-off email address, or phone number and the phone wasn't able to merge it with an existing contact automatically. We have identity providers that can only represent a small portion of our identity, real names on Facebook and Google+, but cannot resolve that back to our phone numbers or find the best way to contact us at any given time. Presence, which was the real promise of IM and XMPP (and SIMPLE if you must) is not integrated. I cannot determine before hand whether somebody is available to talk on the phone, would prefer a text message, or if I should leave a push voice message they can listen to at their leisure.
Even calling a company with a well designed IVR is still a confusing waste of time, when the device I am calling that system from is smart enough to contain any identifier or proof of identity that the called party would need, the protocols are artificially limited to phone numbers as identifiers. There is also no out of band solution to this problem, or the the problem of selecting what department I would prefer to speak with about a problem without navigating a menu that the interface on my device is not really designed to use. Think DTMF on an Android device where the screen shuts off.
As most users would prefer the Android compatible version, the forked version would likely be installed by most users as most users would want to talk to Android. This problem would then be easily fixed: someone could just submit a pull request for a fix for this issue and create a way to easily stop receiving messages through iMessage. Even better, the author would not need to stop using iMessage - he could keep using it and receiving messages on Android.
Ultimately removing the lock-in at the client level forces the problem to auto correct itself across the board by allowing users the option of migration and developers the option of improvement.
I very much doubt the Apple engineers who wrote iMessage were rubbing their hands together in maniacal glee, at the prospect of being able to prevent people from ever migrating away from iOS, if they but used the phone number in this specific way.
It sounds like it's exactly what TFA's author assumes: a bug.
Apple has certain well advertised priorities. Interoperability with non-Apple systems is not one of them.
(Not to blame Apple in particular -- non-intropability is coincidentally a common feature among the biggest player in every industry, while interopability is a key feature of challengers. But it's just a "bug"... )
If the bug ever surfaced or was ever thought of by anyone at Apple at any point in the development process of iMessage, Apple will have effectively accepted to lock the user in by not having it fixed or communicate about it in some way.
The OP must not be the first to report the problem either (he switched after iOS7, iMesssage was more almost two years old by then) ?
This might not be an issue Apple cares in any way, and that's fine for them. We should just recognize their shitty behavior, even if it's originally accidental.
When I (UK) switched in the late 2000s, it took about an hour.
I've read some porting horror stories online over the years. Yours is probably something like the 6th or 7th. I assume things do sometimes break, but it doesn't seem to be particularly frequent, considering millions of people switch carriers every year.
I will say this though, switching mobile goes rather well almost all of the time. Porting numbers on fixed telephone lines is much more apt to fail.
Even the 'good' behavior in this case is awful. Why would a text message fallback to MMS rather than SMS? I'm pretty sure it's because Apple wants non-iPhone users to think of their phones as broken.
The software I'm using can't solve that problem.
He would also have lost other benefits, such as convenience, automatically using data instead over SMS for casual chatting, using the method he damn wanted, etc.
What having a problem like this justifies is FIXING the problem, not not using the technology in the first place or some ideas about proprietary and OSS.
Not to mention those are beside the point. Even if he DID use a proprietary messaging solution, he might very well have the same issue. It's not an issue that stems from being proprietary, it's an issue that stems from a stupid caching implementation. If some FOSS mobile chating app had the same bug, he would have been bitten by it just the same.
I don't see the need for absolutely open hardware for an alternative messaging system. Sure, they aren't FLOSS solutions, but they are much less closed than iMessage and are cross-platform.
Note: Hangouts is an abomination.
I'm not 100% clear on this: why can't there be an open mobile OS that runs on (bootrom-exploited) iOS devices?
Sure, you can use proprietary hardware (iPhone) and try to make it run different software, but your luck getting around their protection systems may vary (and it may or may not be illegal, depending on how much you care).
Hell, it can be difficult to get an unsupported version of Android to work without major bugs on an Android phone.
They had to rewrite the drivers, of course.
[0] - https://whispersystems.org/
[1] - https://telegram.org/
XMPP is _the_ standard, with just so many[0] implementations. On mobile, a good choice is ChatSecure, or Yaxim if you're on Android.
> that lots of people use
XMPP certainly doesn't meet this criteria, it would have to be IRC... but that's yet another way of modelling your social interactions.
The problem with XMPP (or any IM protocol for that matter) is that if nobody uses it, there will be little technical progress, which means few people will use it, etc...
This is not comparable to the normal performance of SMS or iMessages.