[moocowtruck]

because the source is important, it tells the buyer they have a future if they no longer like your services; closed source means they are locked into whatever fresh hell might come upon your company which in turn unleashes fresh hell upon their decision to buy in.. in 2018+ it's just a smart decision to make

[manigandham]

The vast majority of companies can barely build their own products, let alone study the source code of complex 3rd-party software. A distributed SQL database is on the extreme end of knowledge required to even understand it, so I'm not sure how open-source is going to help you.

As a counter-example, rethinkdb is open-source but the company failed and nobody cares about using it anymore. What would you do with that? Start building new database features yourself? Or just get your data out and move to a different system?

[zzzcpan]

You will be able to at least maintain it, fix bugs, security issues. Maybe even start working on new features, promote your fork, revive some of the community, find people with relevant expertise, etc.

Databases are so lock-iny and critical that it's only natural for closed source database startups to be considered too risky to touch.

[manigandham]

Possible doesn't mean realistic. As stated, 99.99% of companies are not going to come close to understanding, forking, and running their own build of a database.

It's better to practice proper vendor management and weigh all the risks and realities instead. If you're not more capitalized and viable then your vendor, then you have more important things to worry about then your vendor disappearing overnight.

[paulsutter]

/Widely used/ open source projects will find continued support; the user base of a project is a crucial part of the decision. Rethinkdb had only one serious site, who found it easier to port to a thin layer on top of Postgres when rethink collapsed.

[rtpg]

That's not a technical decision though. That's a business decision.

A real technical reason might be "the ability to fix the software ourselves" or "easier debugging of the software". Avoiding vendor lock-in isn't a technical decision

[shin_lao]

Good luck with the source code of a database you didn't write...

[jessedhillon]

I recently was able to unfuck my way out of a 300GB data loss resulting from a failed DB upgrade. By looking into the commit history of PostgreSQL, finding the commit with the PG_CATALOG_VERSION I needed, and compiling from that revision, I was able to re-run the upgrade with the parameters I needed. I'm not sure what I would have done if that had been MS SQL Server or something else.

[manigandham]

You would send in a support ticket to the company and they would solve it for you.

[mmt]

> they would solve it for you

That hasn't been my experience, at least not on any suitable time scale.

I strongly suspect that the vast majority of those of us who have worked somewhere "not more capitalized and viable" than the vendor share that experience.

Even when a vendor's support engineer is fully capable of solving the problem, the sense of urgency can't reasonably be expected to match that of a much smaller customer facing potentially catastrophic data loss (or other existential-threat-level consequences).

[manigandham]

Vendors have support plans and SLAs so if you need 24/7 support then make sure that is indeed what you're paying for.

I do not see how having spare engineering talent capable of reading, editing and running a custom database build is the more realistic or faster option for any business in case of issues.

[mmt]

> Vendors have support plans and SLAs so if you need 24/7 support then make sure that is indeed what you're paying for.

Those are totally useless during an existential crisis without associated indemnity (which any vendor would be crazy to provide) against loss due to failur to perform.

> I do not see how having spare engineering talent capable of reading, editing and running a custom database build is the more realistic or faster option for any business in case of issues.

I don't see how it isn't, considering that "custom database build" could be so simple as to be trivial. In the GP's case, it was merely using a specific version.

Even the characterization of the required engineering talent as "spare" seems incongruous, as, in small companies, the talent requird to handle unexpected problems with technlogies fundamenta to running the business is essential, not superfluous.

[jchanimal]

The proof is in the pudding. Plenty/most serious users of open source databases become customers of the relevant companies. The commercial license is usually a small fraction of the potential cost of an outage.

[azifali]

While plenty of closed source software systems are still being widely used, I think the world is dramatically moving towards open source. The world has changed and I think these expectations of being able to leverage an open source software is here to stay. This despite the fact that a vast majority may never actually read, fork or modify the source code.