The “Chemistry-centric” front end bit of the ELN problem isn’t really our gig – although we’re happy to play our part in enabling the deployment of such products to Chemists whilst we keep everyone else in the organisation happy. So we see a lot of Chemistry ELNs but we don’t really have much interest in them apart from the fact that some of our users use them.

However, my inner geek keeps looking at the existing Chemistry ELN products from a technical perspective and thinking:

  • They’re mostly based on quite old platforms. Web 2.0 isn’t really making an appearance – this is very traditional enterprise software with all the associated problems.
  • I’m not sure what value these really thick clients are adding. Seems like a really expensive and painful way to make Excel harder to use, and are a general support nightmare.
  • What’s going to happen when someone takes something like WordPress and adds structures to it?

The more I play with things like WordPress and Rails, the more impressed I am with what can be done with web UIs. And then I bump into things like Metamolecular’s ChemWriter and I think the future will be rather exciting…

The next question is if these solutions will come out of the Open Source community or commercial providers. Having met some of the guys in Academia I suspect it’ll be taking what they’ve done and bending it slightly to the needs of commercial organisations (plus adding support services etc.)

Anyway, hopefully all of this innovation on the front end means more people with the problem our PatentSafe product solves. Which of course is delightful…

 

DRM is beginning to make an entrance into the Enterprise, and whilst at one level the technologies sound attractive I’m not sure the longer term, deeper consequences are all that palatable. I do wonder what the lawyers will think (because a Judge is unlikely to be impressed by arbitrary restrictions imposed by some DRM system) and of course from a long term records perspective DRM is completely toxic.

James Governor’s MonkChips: digital lard for the enterprise: DRM meets document formats: “What I am saying is that DRM creates new escrow challenges, and organisations should know exactly what they are using it for, and why, and what risks they are mitigating, before embarking on an enterprise DRM strategy.”

 

Microsoft are fighting hard against the Massachusetts decision to mandate the Open Document file format in preference for their own proprietary “Open” XML based formats, and this is providing us all with a great education into Open File Formats in genetal.

Firstly only did Massachusetts make their decision in a very public way (so we can all “see their working”), clearly documenting why they felt Open Formats were important from a business perspective, and how they defined what one way. Now the resulting backlash from Microsoft is producing an awful lot of good analysis about the problems of file formats, which is very relevant for companies considering ELN purchases.

To me, this is increasingly looking like the end of proprietary file formats (and hence the use of file formats as a commercial weapon) and the more the vendors kick & scream, the faster their customers will understand they need demand the protection that Open Formats provide.

Groklaw has a really good wrap up of all the issues and considerations with pointers to other material. If you haven’t been watching this then it is a good first place to start your research into why Open File Formats are a crucial consideration in any ELN purchase.

Here’s a particularly relevant quote:

Few leading vendors ever really want to have an agreed-on open standard, because that opens the market to competitors. But once a technology stabilizes, wise customers demand standards that let them pick between suppliers, and customers are the ones paying the bills. This happens all the time, in all technology areas.

 

So after a bit of meandering, the State of Massachusetts is backing the OpenDocument standard as the standard format for office applications. At one level this is just another example of how customers are revolting against proprietary file formats (which lock them into the vendor) and demanding Open, vendor-neutral formats. But MA’s decision is a particularly important one because it appears Microsoft fought hard for the Microsoft Office Open XML formats, including a significant amount of lobbying and some quite amazing (MA-specific) adjustments to some of the nastier aspects of the Office XML license.

As a result of this, the community has had the opportunity of seeing Microsoft’s “Talking Points” and soundly rejecting them. We’ve also seen how desperate Microsoft is to protect their Office cash cow.

Why is this important for Electronic Lab Notebooks?

  • It demonstrates (yet again) that Open File formats are an issues that needs to be taken seriously at the highest levels. Hopefully as governments around the world begin to insist on open formats, corporates will be being to take the problem seriously too.
  • The arguments vendors use to justify their proprietary file formats are increasingly being shown to be false.
  • The increasing experience with open formats shows that it isn’t that hard to build systems that are open, and give customers first-hand experience of the benefits of Open Systems.

Electronic Lab Notebooks systems benefit more than normal from open file formats because:

  • Almost ELN systems are made up of software from more than one source (commercial vendors, as well as a large number of small, focused applications developed in-house).
  • The information in ELN systems often needs to be accessible in 30 years or longer (“Lifetime of the Company” is very typical). The chances of the original application being available is minimal.
  • ELN systems often need to do an awful lot of unusual stuff, which wasn’t anticipated by the original designers. Yet the market for ELNs is comparatively small compared to the overall market for products like Office. So ELN functionality is often an after-the-fact addon implemented internally or by niche vendors (like my company, Amphora).

My feeling is that the market is going to punish ELN vendors who are still holding to their closed proprietary file formats, and preventing their users getting access to their data (by not releasing APIs). I spoke to one vendor at a conference a few months ago and he was genuinely confused why anyone would need their data outside their ELN – and felt strongly that moving to an open file format would be unduly hard for them. Duh. All they’d have to do would be to publish their internal documentation and they’d be OK – no code changes required. But that would require giving up control….

In contrast, there are ELN suppliers who do strongly support open file formats, and encourage our customers to access their data which is stored in our systems, etc. Our PatentSafe product is one, but there are many others. Did I mention we’re growing like crazy….. I guess the market likes vendors who look after their customers’ interests :-)

For more information you might want to readWhy OpenDocument Won (and Microsoft Office Open XML Didn’t) by David A. Wheeler. There’s also a very interesting letting from Adam Barr (of Microsoft) to Jeff Raikes (Group VP at Microsoft) explaining the reasons for Massachusetts’s choice, and why it shouldn’t be a problem for Microsoft to work with open formats rather than resisiting. Replace “Microsoft” with your favourite ELN vendor and see how it feels…

I hope it won’t be long before companies start to require “that all electronic documents “created and saved” by state employees would have to be based on open formats”. That will be a major advance for the interests of customers.

 

I am extensively quoted in this article in Scientific & Computing World on the importance of Open Data formats.

© 2011 elnblog.com Suffusion theme by Sayontan Sinha