Not totally, not till Oracle has been tipped into the dustbin of history. (Come the day!)

I think Cisco still uses proprietary software too.

With Oracle's strong ties with government structures, it's unlikely that it will be gone in the next 30 years.

I'd say that the cutting point is when no new project considers Oracle as a viable tool. This time has largely come already.

Fair! Although I've never worked with a shop that was not-Oracle and migrating to Oracle. Sadly, there's the long tail of places with existing, business critical Oracle use.

Anyone that wants top tier RDMS, it nice graphical debuggers for stored procedures, integration of Java and .NET into the database, distributed transactions, raw file system accesses, web services on the DB layer, among several other features, besides Oracle, there is only MS SQL Server and the RDMS owned by IBM like DB 2 and Informix.

MySQL and Postgres are kind of nice, but not really the same league at tooling level.

This is completely in line with the premise above.

If the database is primarily a data store, unseen by the end user, then Postgress, Firebird etc are fine. If however the database is an active part of the development stack, being used by lots of "users", writing new code etc, then commercial offerings with better tooling win.

Yes you’re right. But OSS opens up a free market of vendors. Consider how Wordpress powers 40% of all websites in the world. The website owners pay hosts etc. to have full control and they arent locked into a monopoly vendor, but end users just use the stuff.

Yes. Open source software people very rarely do good graphical user interfaces. Unclear why this is so. But it is.

For making a good GUI, the tech guys need to be ordered around by non-tech guys who think like, or talk to, regular users and know what is needed. Tech guys don't like this, so someone needs to pay for their suffering.

I suspect Dijkstra made the relevant distinction in a different context: the open source process is geared to providing correct software, not pleasant software.

> The pleasantness problem deals with the question how satisfactory a system meeting a given functional specification would be; the correctness problem deals with the question whether a given system meets that functional specification. The correctness problem being an entirely technical one, the functional specification can provide strong heuristic guidance for the system designer.

You have clearly not see the user interface of most (as opposed to the most popular) pieces of closed-source software.

That's not really a rebuttal though. 90% of all UX can be bad, but it's still notable if 99% of OSS UX is bad.

Actually needing to sell your product eventually/get people to use it seems to be a fairly necessary part of ending up with a good UX.

I never considered this differentiator before, but it makes sense.