OpenQRM vs. vendor lock in???

So, I thought I'd forget about the (not very successful)results I've got when investing some days into testing and evaluating - trying to build and install and get started with OpenQRM.

But then, I read this and that.

Really, guys, as for Vendor lock in, I think OpenQRM sits in the glass house:

My install is (because OpenQRM forces man own versions of libs available in each distribution, and not even the JDK is reused) 500MB - big binary blob.

It has been already discussed widely on their mailing list that OpenQRM wouldn't even let me change an IP address easily, because it "thinks" it should not be done, even if I _know_ exactly that the change cannot cause harm. So it enforces(or locks me into) a very specific structure and workflows to handle my datacenter.

When I decide to start using this as a main part of my infrastructure, and the whole things stops working, I guess I am totally locked in to buy support from qlusters, as it will take ages to understand the whole build system and source code before anything can be fixed.

Even for security updates of all the dependecies of OpenQRM I am locked in: instead of using the ones that come with a distribution, it brings own versions for many of them. If a grave security problem is found, I have to wait for the QRM developers to bring a security fix, instead of simply relying on the security support of my distribution vendor.

Maybe I am completely wrong and look at the things from a strange perspective, but that's my current opinion on the things.


To keep this post positive and constructive, some proposals for getting leaner, cleaner, and forcing less to your users:

  1. Build against standard versions of libraries as they come with some distribution. If you have trouble building and developing against the multitude of lib-versions in many distributions, I'd say, better concentrate on one distribution and create a clean and small package. If your product is cool enough, there will be package maintainers from other distributions that will package it one day - or a customer will pay you to make it running on his favourite distribution. OpenQRM forces so many things, settling for a specific OS for the management server is a minor thing then. This has many advantages:
    1. smaller code base at build as well as runtime leads to faster build, and easier error tracking
    2. "free" security updates by distribution vendors
    3. Enable OpenQRM being included in distributions and being available from their main software(yum/apt/yast...) repositories. They will not include it as long as it requires it's own combination of lib versions. other than the standard ones (imagine every app using it bringing it's version of rsync?!)
  2. Instead of simply forbidding some things for all users(like chaning an IP address of a storage server), give experts some way to force doing a change you consider "not good", so people knowing what they do can force it.
  3. In general, look for ways to keep your code base and runtime binaries small. By letting the user chose at install time to use a locally installed java runtime, for example, you can directly cut stuff in /opt for 100MB.