Don't get locked up into avoiding lock-in

I recently did some 'lock-in' consulting with a company who had heavily committed to an open source database. The database had two versions, community and enterprise, previously both were open source with the enterprise version optionally being supported by a service contract. The company then changed the license of the enterprise version to a closed source pay only subscription model with a HUGE yearly license fee. The tech team are now eating major crow from the business side of the company. I ultimately recommended that they rewrite the data access layer to use PostgreSQL. Which they are doing, in the end it will result in a more modular and extensible application architecture. Lock-In is something that should be avoided.

I notice a pattern (no pun intended) to this web-site, in that it advocates things that the open source community (and many programmers in general) shy away from, like:

- eagerly rewriting working code

- diving headlong into complexity rather than minimizing/avoiding it

- pro enterprise software with the implied lock-in cost

- promotes the artificial concept of software manufacturing with it's basis in "design patterns" that are seldom used in any meaningful way in my observation

I am not saying there is nothing of value here, but it seems to hint at a kind of propaganda against a growing consensus around agile/lean development.

My 2c.

I'm not sure who the appropriate audience is for this article. The writer seems to be genuinely trying to convey that lock-in isn't good, but isn't the be all end all, which everyone knows. Lock in is avoided not by looking at software stacks but by following standards that translate with minimal friction across more than one platform, unless your a highly specific use case that requires lock in due to heavy tuning. Sometimes lock-in can't be avoided, most times it can. Open source has literally nothing to do with lock in unless you're building directly on top one that product. It's just a development methodology that provides resiliency against losing access to the software, as long as you're willing to build any future improvements yourself if it gets locked up, which in a way provides a slight buffer against lock in, but maybe he runs in circles where people all think open source software is magical.

Blowhard appropriation of the concept of avoiding being tightly coupled. Of course we cannot avoid coupling; the point is to make coupling as loose as possible.