More on DropBox’s Terms of Service – run away…

Interesting post from Dave Winer on Scripting News taking a look at DropBox’s possible business plan, which gives me more worries about using DropBox as the basis for an Electronic Lab Notebook.

That means they have to be looking inside your box to get the data they’re going to aggregate, to get to that astronomical valuation. That’s why they didn’t just go with the enterprise-y user agreements that Microsoft and Amazon use. They don’t want your money. They want the advertisers’ money.

What’s inside your Dropbox says a lot about you. And that, of course, is what Dropbox users (like me) are afraid of.

If that’s the case, you’d have to be very brave to use DropBox for Science that wasn’t already in the public domain… best stick with solutions focused on solving the ELN problem, which have the appropriate technical and business architecture! We’d love to talk to you 🙂

Cloud Applications, ELN & IP

I’ve met a number of groups who are using Commodity “Cloud” services (Google Apps, DropBox etc.) for their Lab Notebook data, and whilst it works well technically (and is always improving!), I’ve always wondered about the IP/Confidentiality issues.

I bumped into an analysis of the Terms of Service of various Cloud service providers on Neowin. It isn’t encouraging reading.

I can empathise with the providers; they are providing a generic service to a large number of users, for free or a very low price. The only way they can execute their business at that scale is to tell people “We get to see your data too, and we can re-use it or give it to other people for whatever reasons we decide”.

Unfortunately, that’s not pretty from an IP perspective. I’m no lawyer but I can’t see how some of these terms and conditions are compatible with securing a company’s IP via Patents or even Trade Secrets (let alone personal privacy).

Caveat emptor!

Interestingly Amphora have found ourselves increasingly providing Cloud-like and SaaS-centric services to our customers. We started providing PatentSafe as SaaS but then we’ve moved into providing offsite backup (using a private CrashPlan service) and other services.

In meeting this customer need, we’ve had to do it with our normal IP-centric Terms of Service – which basically means your data is private to you, and we’re only going to disclose it when you ask us (or, in the extreme, when we get a court order). That’s been hard – it has caused us to shy away from some “Cloudy” infrastructure that I know some ELN vendors have gone for, e.g. the Amazon EC2 and S3 products to name just two. Ultimately that means our costs are higher, but to do otherwise would be irresponsible.

I’d like to say this is a matter of “You get what you pay for” but it isn’t as simple as that – these commodity services are just focused on a different market. So before you get the Cloud bug in the Lab, read the Terms of Service and consider if that’s appropriate for your circumstances. When you’ve done that, check with your provider – do they run the services themselves, or do they use another platform – if they’ve got it all on Google or Amazon infrastructure (excellent technical choices! legally trickier) it is worth taking the time to understand who your contract is with and what is happening to your data.

ELNs and Data Portability

I recall back in the late 90’s a lot of discussion at CENSA meetings about the need to move data between different systems, and of course from one ELN to another. From the customer’s perspective it is a really important issue although sadly one that doesn’t get enough attention until they are committed to a vendor – and of course it isn’t in the Vendor’s interest to allow you to take your data somewhere else… to a competing product for example. We even sponsored the development of CENSML (Collaborative Electronic Notebook Systems Markup Language) which was meant with complete apathy and interestingly no one else proposed anything similar.

So at this time the data portability situation in the ELN world is pretty awful. Which is a shame, and at some point people are going to start noticing – and perhaps the next round of ELN purchases will have open file formats as a purchasing consideration.

I came across the Data Portability project in this article on Tech Crunch which seems to be a really nice way of at least making the Data Portability issues obvious to consumers. They are starting off in the online web app area but clearly it is very relevant to any IT system, either cloud-based or on premises.

For the record, Amphora’s systems are completely open – our view is that it is your data and you should be able to take it where you want, when you want, without even having to involve us.

In addition, our focus on IP means we need to be able to reassure our customers that they can take a record out of our ELN and defend their IP long after their relationship with Amphora has come to a close – with a 50 or 100 year retention timescale, requiring the vendor to be around just isn’t acceptable (which is a big concern with services that claim to outsource IP protection, something I’ll blog on in due course).

We take this a step further in our Hosted/SaaS offerings, where customers can take a copy of their data (via rsync or similar) onto another server controlled by them every night. We also work with those customers to make sure they can spin up their own server as needed. This means that even where we’re Hosting them, they can tell us our services aren’t required and still have complete access to their data without any cooperation for us.

We believe that open data, neutral file formats, powerful APIs and above all a respectful policy to our customer’s IP are the cornerstone of any ELN vendor’s offering.

Our next web site refresh will contain our Data Portability policy. In the meantime I can only hope that as various advocacy groups get more vocal about the need for Facebook, Twitter and others to unlock your data, that will cause Data Portability to be given the consideration it deserves in the ELN world.

SaaS: Shelfware as a service? | Between the Lines | ZDNet.com

Interesting perspective on the whole SaaS debate on the ZDNet Between the Lines blog in their post SaaS: Shelfware as a service?.

Basically SaaS is not a magic bullet for enterprise apps, the problems associated with large complex software can’t be magicked away just because someone else runs the software for you.

Our hosted products and SaaS products are identical, as is our deployment methodology. I’d like to think we’ve put in the design time to ensure that deploying a replacement for the paper notebook is as painless as possible. That’s the result of experience and careful design, which I hope produces the same results regardless of how it’s deployed – on premises or SaaS. That some of our customers find purchasing our products as a Service is more a matter of convenience and economic preference.

How SaaS changes the Vendor/Client dynamic for the better

There’s a blog post on SandHill.com about reducing the cost of SaaS implementations.

The first few paragraphs really hit home:

In the on-premise enterprise software world, I have seen many software implementations go awry despite ballooning implementation expenditures. Customers never see their ROI until many years into the implementation, by which time they are so deep into upgrades, manpower turnover, shrinking IT budgets, IT organizational fiefdom – you get the picture – that ROI is the last thing on their mind.

As the customer struggles, the software vendor bears very little risk. The company has pocketed the license dollars and issued the press release on the customer acquisition.

With SaaS, the tables are turned. The SaaS software vendors (to their own detriment) have perpetuated this notion that, with SaaS, implementation will be effortless. But as we all know, enterprise software implementation is much more than just installing the software. Vendors must work harder to reduce deployment cost and improve ROI for their customers. Here’s how.

There’s two components of SaaS – where the software runs, and how the client pays the vendor. In this post I’m going to focus on how the vendor gets paid because it forces some interesting changes in vendor behaviour.

A traditional software sale goes something like this:

  • The hero salesperson goes in, does a magnificent sales job convincing the client that the package is wonderful and the vendor is deeply committed to success.
  • Customer issues Purchase Order and our hero salesperson exits stage left, pocketing his commission as he goes.
  • The vendor’s implementation team are then left to fulfill the commitments the salesperson made, within the sometimes very considerable constraints of budget, time, and technical feasibility (constraints that seldom bother the salesperson!).
  • In most cases the implementation effort is a matter of containing the damage rather than achieving something positive, and is the principle reason why there’s so little trust between customers and vendors.

Meanwhile, the customer’s business has stumped up a large capital sum in the hope of achieving some return at some point in the future based on the salesperson’s promise. All the risk is on the customer’s side at this point, because they’ve got an awful lot more invested than the vendor.

If you think about it, this is nuts. The vendor is selling an intangible – there’s no justification for a large up-front capital sum except to fit into the vendor’s existing financial model and sales compensation plan. Why can’t the customer pay for value received as it’s received?

I suspect the current state of affairs is just a matter of tradition, software companies have until now been able to get away with it – they haven’t needed to wean themselves off the up-front capital sum. Now capital is much more constrained so things are changing and customers are expecting to pay as they receive value.

Aside from making the finances easier, what’s really interesting is that rental now means a shared risk between the customer and the vendor – if the customer doesn’t get a return they won’t renew. That makes for much more open and honest conversations, and importantly from the vendor’s side, there’s a lot more learning going on – you really do have their attention. Chances are the vendor will need to change internally to respond to the new demands of this “Shared risk” approach – although one might wonder why it took this long to start caring about the customer’s outcomes.

Amphora started offering rental-type pricing for PatentSafe from the start, and I’m sure it’s one of the reasons why our products are some of the easiest ELNs to get going with, and deliver ROI with reasonable certainty. In addition, we’re wired up internally to ensure we learn as much as possible – we have a board-level position of “Director of Customer Relations” and the salesforce report into her which means one person has control over the entire customer experience from first touch to ROI realisation.

I should say that not everyone takes the rental-style option – I guess probably 50% of our customers rent in some way or another, Vs outright purchase. Getting so much of our revenue this way really forces us to pay attention and ensure the customer gets the business benefits we sold them – because if they don’t they will cancel! Our contracts also have short notice periods which means we never take anyone for granted, a deliberate decision on our part – it means we catch problems early.

Some customers don’t like this partnership approach – they’d rather buy the software and take responsibility for ROI themselves, taking the view that they know their organisation better than we do. Which is perfectly fine – some customers are amazingly professional and we just watch in awe. Other customers sometimes need a little help 🙂

I guess the point is traditional software pricing means that a successful project is mainly the customer’s problem. Rental/SaaS-style pricing means both parties interests are aligned.

From the vendor’s perspective this is hard work but it makes you a better company in the end – better products, better services, better (and more ethical) sales. Yes you lose the big upfront windfall of outright purchase, but if you aren’t needing to artificially inflate your short term earnings and can manage your business for the longer term, that’s not a problem.

Yet another way in which being privately held is an advantage, I guess!