
Don't get locked up into avoiding lock-in - scarface74
https://martinfowler.com/articles/oss-lockin.html
======
Railsify
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.

~~~
deogeo
Could they not still use the last open enterprise version? At least until they
can migrate. Which is troublesome, but at least buys you time - something you
wouldn't have if the database never had a free/open-source version.

~~~
Railsify
Yes, that is exactly what is happening.

------
tus88
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.

~~~
scarface74
_diving headlong into complexity rather than minimizing /avoiding it_

Most web frameworks are far from “minimal”.

 _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_

Too many companies think their yet another software as a service CRUD app is a
special snowflake where they need the top 1% “ninja Rockstar developer”.
Usually there are well known patterns.

------
cannonedhamster
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.

~~~
tlocke
Isn't it true that you can avoid vendor lock-in with Open Source because you
have a choice of companies that will support it? For example with PostgreSQL
there are a variety of companies that provide support.

------
lidHanteyk
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.

~~~
scarface74
And how many “architects” have said that they want to use the repository
pattern just in case the CTO wants to migrate from their million dollar Oracle
installation? How many hours of effort have been put into avoiding lock in,
coming up with more complex patterns in the rare event that someone is going
to change their entire underling infrastructure.

