@Timo-Martosatiman-MRA
Hai Timo,
Point is that your efforts came too late. You entered an environment that was already completely locked in, and whatever you suggested to get out of that situation made everybody realize how tight the lock was, and how much work it would be to break the chain.
When I was evaluating vendors for a rather large organization, one standard question (which was afterwards firmly tested) was: "which standards do you fully support to move all data from - whatever it is you are trying to sell - to any other platform. And yes, sometimes this aspect was the determining element to select a vendor.
But, on this issue, and as an example only: remember Photo Bucket that unexpectedly changed its ways into charging a lot for its services, and practically holding its user's data hostage.
I am not questioning the health of MRA and this is not even suspicion that you would do something similar as photo bucket, but MRA (like the rest of us) does not control all aspects of its future, and events can lead to disaster. We usually discover the weaknesses behind our business continuity and disaster recovery systems by painful experience.
Transferring 20? years of travel data to MRA, and everything I will produce in future, without any decent option to retrieve all that data in case of need (whatever causes that need), is not a matter of "panic hoarding at MRA" but of voluntary vendor lock in, without any back-up, except when done manually. This is contradictory to using a system like MRA build to making fun of routing. Remaining polite, it's not a clever move.
Would you buy an IT system that does not facilitate making a back-up? I am quite hesitant knowing that there is no realistic way back which is putting the brake on what I do with MRA.
If the needed bandwidth would scare you then you could easily limit the back-up option to one download a year.
