Hacker News new | past | comments | ask | show | jobs | submit login
Don't get locked up into avoiding lock-in (martinfowler.com)
38 points by scarface74 51 days ago | hide | past | web | favorite | 11 comments



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.


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.


Yes, that is exactly what is happening.


Was this by any chance Cassandra? Sounds an awful lot like what Datastax did a couple years ago.


I don't want to be too explicit but there are several cases of this in the past few years. The playbook was the same as Cassandra. Open source as a marketing tool...


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.


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.


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.


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.


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.


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: