Evernote was quick to backpedal and change to an opt-in model following the fully justified outrage of its users. It’s quite possible some users no longer trust Evernote with their data after this two-step, and it would be hard to blame them. It is possible to store data locally with Evernote (by creating a local notebook instead of a “synchronized” notebook) and they intentionally make it easy to get all your data out of Evernote if you want to leave for what you believe are greener pastures. This gaffe might be the impetus for quite a few users to do just that.
The lesson here is a very powerful one: there’s very little stopping other companies from doing this tomorrow, and there’s no guarantee the CEO of that company will even give the appearance of giving a tinker’s damn about its users. This is a rather direct reminder to take a look at the companies you trust with your data, and how easy it would be to get your data out of those services/products should you decide you want to leave. Of course, it would be wise to remember the best time to find out how easy it is to get your data back out of a product/service is before you put your data in it.
I’ll add a personal angle to this. At various times over the past year and change, I have considered moving this blog to a static site updated with Pelican, among other possibilities. The hard part is not getting the data out of WordPress–that’s actually about as easy as they get. Even the free-of-charge wordpress.com platform makes this relatively easy, even if one is not moving to self-hosted WordPress (a.k.a. “wordpress.org” to differentiate it from shared-hosting wordpress.com).
No, the problem comes if I find out Pelican (in this case) doesn’t work out and I have to move entries back into the last backup of the site as a WordPress site. That might be easy if I make no more than about five posts before finding out it’s not going to work out. But what if that’s ten? Twenty? Fifty? One hundred? Two hundred? It’s a potentially painful process because I don’t see an easy way to automatically make even a WXR file with the new posts in it. Sure, I could ease any future transition by keeping a local install of WordPress and add the new posts manually as I make them, but that is an implied admission I have no confidence in the new platform–and that would be the case even if it was something besides Pelican.
Of course, ideally I want to change platforms only once. There’s always the chance the first change doesn’t work out. There’s also the chance I would want to later switch back to WordPress after making this change, or switch to a future WordPress fork or even to something like b2evolution (which forked from the same blogging software that WordPress was forked from).
Another great example of what not to do, unfortunately, is what the WordPress Foundation (at the time) did when they struck a deal with Meetup.com regarding the online presence of local WordPress groups. The thing to remember about Meetup.com is that they intentionally make it difficult to impossible to change platforms. Vendor lock-in, combined with the (justified) fear that organizers might lose some members (in fact, almost certainly will lose some members) when transitioning to another platform, is the business model of Meetup. It’s a huge departure from the Meetup that I used as an early adopter and that’s sad.
Anyway, it was and still is really disappointing to me that the WordPress Foundation (at the time) deciding to just pay a bunch of money to Meetup. The first reason is it’s been sort of an informal goal of the WordPress community to do everything with WordPress that can be done with WordPress. As an example of this, WordCamps aren’t ticketed with Eventbrite or other such sites; they use a WordPress plugin called CampTix written for the purpose. Thankfully the deal with Meetup.com is about the only time WordPress was intentionally eschewed for a function central to the local WordPress communities around the world.
Adding to it, of course, was the unfortunate experience we had with the Houston WordPress Meetup in most of 2012 going into the early months of 2013 and the response from Meetup (at the top of the post). Basically, Meetup’s standpoint was that the people (community) in the group didn’t matter as much compared to the organizer paying their dues on time. The only silver lining to this cloud is that the WordPress Foundation (the entity paying Meetup which is the nominal organizer of the actual group; maybe this, too, has changed to WordPress Community Support, the new PBC) has a bit more skin in the game and can replace inactive or unresponsive organizers. Then again, they would still be able to do that using a home-brewed WordPress-based solution, without paying Meetup one bloody cent.
Regarding the use of Meetup, it’s hard to see which is the chicken and which is the egg. A lot of groups were using Meetup.com prior to the WordPress Foundation deal. Still, the better move for the community would have been to start a WordPress multiuser site similar to wordcamp.org with a plugin to replicate the Meetup-like functionality in much the same way CampTix fills in for Eventbrite. Better yet would be a fully free software alternative (GPL, if need be Affero GPL) to Meetup.com; even if it is not built on top of WordPress, that would be a step in the right direction.
Examples are plentiful, but the lesson remains the same:
- Know how to get your data out of a platform before you need to. If unsure, ask questions. If you don’t like the answers, use a different product or service instead, after getting satisfactory answers to the same questions.