|
If I'm understanding things correctly from the reading (which, let's be honest, that's an assumption on its own), the tl;dr seems to be that Mendeley heard about an open source product working on a set of importers that would, potentially, result in Mendeley customers migrating to this free alternative[0]. To provide cover for this change, they invoked user security. And hey, user security is a pretty good reason to encrypt a database, but if security were the only aim, they could have made the data accessible for export purposes (after all, it's accessible for the user to read). At this point in history I'm not even sure it's worth going into all of the reasons this is a terrible thing to do on their part. At best, they'll scare off some users from migrating away briefly and buy themselves some time to figure out what they need to do to produce something that's better than the competition they're attempting thwart. More likely, they'll simply fail (quickly or slowly). It's that last point that really matters to me. If I'm buying an application that I'm going to rely on, I want comfort that the company will continue to maintain the product -- or in the case of open-source, confidence that the product is still regularly maintained (or in languages/frameworks that make it practical for me to maintain myself). Aside from the fact that I wouldn't want that feature 'as it has been designed, today', I wouldn't want to rely on a product that's being designed by individuals who aren't well versed in the perils that DRM-like behavior causes. After all, that's what this is -- it's an attempt to keep the user from transforming their own data for the purposes of locking that customer into the product while attempting to position the lock-in as a security feature. And it failed on both accounts, Zotero worked around the encryption (which means the bad guys can to) and if people looking for a product like this care about that capability, they'll likely refine it to the point that it's as capable encrypted as it is decrypted. Every time I've been asked to implement a DRM solution I've either outright refused or paired it down so much that the "R" didn't really exist. They're horribly complex to write, off the shelf solutions are already cracked and time would be better spent giving customers something they're willing to pay for. The thing that makes me roll my eyes every time I read one of these is "there are still engineers out there who think this is a good idea?" I can't wrap my head around what causes this kind of thinking -- it's not a zero-sum game, there's room for more than one product in the marketplace -- even if one of them is free and open-source. Trying to beat the competition by sabotage rather than by making a better product doesn't work ... at least not for very long. [0] And they also do my least favorite "other marketing thing" -- "Create a Free Account" and no hint of what the thing costs in any obvious place. So maybe this other product is free? I doubt it -- Like most companies, I'm assuming they're perfectly happy collecting your personal information for free (in order to send marketing to you to get you to pay for whatever service is tied to the free account). It's the little deceptive things that drive me crazy -- you didn't trick me, you only managed to make me suspicious of your product. [1] I've gotten lucky ... usually budget and time doesn't allow for wasting energy on customer-hostile features that won't achieve the ends they're aiming for. The only case where something "DRM-like" was in an application I wrote was to be the opposite of customer-hostile. We had an app that provided information to users based on their permissions, determined by them logging in. I pushed to make the automation (sending us the login information) opt-in, with manual provisioning options. It worked well, since if they failed to true up after months of warnings, the application would deactivate (due to the size of the customers, months of warning was somewhere near a year and could also be disabled with a flag). |
The issue is that due to Elsevier, a DRM logic was implemented that just doesn't make sense for scientists. The idea is that I can tell you about a paper, but you have to download it yourself because I can not send it to you. I can annotate the PDF, but I can not send you the annotated PDF. We have to look at the same screen to see what I wrote.
That end result means that Mendeley is no longer a good product. It makes scientific collaboration difficult to impossible. Sharing of files, ideas, results and writing is such a basic thing in todays world, that you should really be surprised how a company would think that this is a good idea, especially for scientists who almost always collaborate in loose teams.
But that is was happened, because Elsevier only makes money if the only place you can get any PDFs is their DRM walled garden.
So Mendeley is now bad. And NOW it matters that you can not get your data out of it. And the thing is, these annotations and folder categories, tags and meta-data - that's all specific to one researcher. It can not be replicated. It could be years of work in that database, and Mendeley holds it hostage.