The sad truth is that "anyone can" is frequently still "nobody did, so you're on your own". This well applies to even the most popular pieces of FLOSS.
That's still significantly better than "noone but a single vendor can and you're at their mercy", but just being FLOSS doesn't mean it can't suffer from product lock-in, just that with the hurdle being complexity and not copyright.
Ah, the lock is not something that check the license and tells "oh no you're not allowed". It's a combination of not having something, and complexity to add it. Sometimes, that's because you need something tricky. Sometimes, that's because the project lacks any documentation, is written in a pretty low-level (verbose) language that obscures the high-level picture, and it's hard to figure out how it works. Sometimes, that's because FLOSS != KISS, and there is a lot of FLOSS software that has its own unique proprietary protocols and data formats, and does things in a manner that's completely incompatible and non-interoperable with any other system. I have no clue about MySQL or PostgreSQL internals (actually, I heard a word they're good in this regard), but is the case for various FLOSS projects - I've dug into some and cursed their developers.
If you overcame that and made a patch, but it's not accepted by the upstream - there are maintenance costs. How long would you be able to maintain your own fork of a large software project, keeping up with the upstream? I've tried with a few small ones (say, at a small ISP company, I just needed some custom pppd patches for in-house billing logic), and found it to be not a pleasant experience. I believe it's not just because I'm a lazy ass - I saw tons of forks on GitHub that were slowly rotting away, maintained for some time but eventually forsaken by their authors and far behind their upstreams.
> how's your luck at debugging let alone getting a patch accepted in MS-SQL, for instance?
Duh, none or nearly none, of course.
I'm not saying that proprietary binary blobs are better. There are exceptions, but generally they're significantly worse in this regard.
I'm only saying that just because software is FLOSS doesn't mean one can successfully hack on it and adapt it to their needs, or easily migrate to other FLOSS solutions. Sometimes, they'll be stuck for a while - I think that's also can be considered as a lock-in.
> Nobody made their code complex because they felt like it.
Maybe. But there's a term "over-engineering" too. It's not that someone decides to make things unnecessarily complex, but sometimes they really do.
That's still significantly better than "noone but a single vendor can and you're at their mercy", but just being FLOSS doesn't mean it can't suffer from product lock-in, just that with the hurdle being complexity and not copyright.