On Software: Open Formats & Open Protocols

Let’s kick off the text with the sad-but-true bits of wisdom found here:

So, it looks as if standards are more to be feared than to be supported.

But you will have to work with (or against) some standard any way. The question is just:
An open/external or closed/proprietary one?

Corporations and programs come and go, but the data remains.
And some companies may even start with good intentions but change course over the years.

As an user, I’ve always been wary of closed/proprietary protocols and formats: So I use this cool application from a small shop, that unfortunately relies on some self created protocol or file format. It may be very efficient, but what happens to my meticulously maintained data if this company goes bust (or is bought up, which in the long term, has often the same result)?
Not a problem instantly, but in the future: What about bug fixes, security holes?
Compatibility with new versions of your operating system of choice?

And since your data is now in a safe deposit box, for which you don’t have the key, have fun trying to export the data. Not trivial? Too bad, but you surley will find someone who will do it for you for a little compensation… And then convert and import the data to a new format, hopefully without too much friction loss.

As a creator, to support (or even develop) a non-open, non-standard format can be considered as as advantage or disadvantage.
Obviously, you can tie the customer to your solution. If they are already on the hook, where else should they go if no one else can (easily, legally) read/write the data or protocol?

But you also have to have the brains and manpower to develop and maintain a closed format, to fix bugs and to convince the users to use your solution instead of the x tried and tested other formats. Depending on your abilities, size of your enterprise and salesmanship this may or may not be a feasible thing to do.