5 ms·

I spent several years in securities and derivatives trading and the most frequently cited reason for avoiding open-source software I heard was that, in the even

by seanot 9y ago

I spent several years in securities and derivatives trading and the most frequently cited reason for avoiding open-source software I heard was that, in the event of a major foul up, there was no one to sue if you got sued yourself. It's not that difficult for an attorney to paint you as reckless for using "free" software.

mgkimsal 9y ago
and how often do securities firms sue oracle, microsoft, ibm, sybase and other current and previous database giants?
nihonde 9y ago
Show me an enterprise DB license that offers you better indemnity/liability options than open source. (I negotiated them on behalf of huge clients for many years.)
- rjzzleep 9y ago
  It's not so much the license per se. It's that the setup is done by a third party that can be blamed when something goes wrong. I saw one one contract that was specifically saying that they are insured for 1 mio. in damages. The company for the longest time wouldn't even touch basic firewall rules without having the firewall contractor implement it.
  - nihonde 9y ago
    This is so true, it hurts. I call it The Triangle Of CIO Turnover.
ballenf 9y ago
Nobody ever got fired for buying IBM. I think is the better point or rewording of your point.
- vacri 9y ago
  The state government of Queensland (Australia) has forbidden any further contracts going to IBM. https://www.itnews.com.au/news/queenslands-ibm-ban-lives-on-420969 https://www.itnews.com.au/news/queenslands-ibm-ban-lives-on-...
thisisit 9y ago
In my experience with couple of banks, it comes down to support. Lot of systems in banks are written for longevity. So they frown upon software which might be obsolete or people stop working on them 5 years down the line. A paid software, they reason, can at most release a new version while free might not provide enough incentive for people to work on it continuously. Many also think looking up issues on stackoverflow, google or blogs as unreliable. Then there are times when issues might be specific to installs or data, in which case sharing the logs/sample data (even masked ones) can be risky. They feel comfortable sharing logs/masked data with for example Oracle because they believe it to be safe and locked under Oracle's security guidelines. The 2nd refrain I hear is - security. In case of a major security issue being revealed, there is a general sense that FOSS will be slower to react in releasing a "stable" patch. Comparatively paid software take it as a reputation risk and work towards quickly releasing a "stable" patch. If people have to use FOSS, then they try and search for the paid support flavor. Recently we were looking at MQ software. When we zeroed in on RabbitMQ we were asked to deploy only the paid Pivotal version and not the free version because "support". Sure, these things might not be completely true but for many higher ups paying for something somehow makes them sleep better at night than a "free" alternative.
- tajen 9y ago
  This is wrong on so many levels, I suppose you mostly understand it, but here are the counter arguments: > Written for longevity OSS is much better at longevity than proprietary. Even if the authors all die without will, it is possible to fix the little bugs that prevent you from using the software on [NewTechnologyHere]. I've done it countless times with Java software; If anything OSS is the guarantee that you own your future and that the system will exist in the legacy. > Use paid flavor It's good, but what's better is joining the golf club of a principal maintainer. He's key in paying him to fix the issue you're having quickly and merging upstream.
  - hindsightbias 9y ago
    Most enterprises don't want to own coders to fix/hack OSS. They want a solution, roadmap and 24x7 support.
mianos 9y ago
I spent 13 years writing the core trading system for many of the well known exchanges. We used open source wherever possible because the software tended to be more reliable. That said, clients usually got to request the database and we used Sybase a lot. I have been using Postgres for the last eight years since. every day of the week and I really like it but the planner is quite a bit worse than Oracle, SQL Server's. The postgres planner is still way way better than MySQL's. It still has correlated subqueries explode into cartesian joins. Mysql is great as a data store but it's more of a replacement for noSQL than an advanced query engine.
- barrkel 9y ago
  MySQL's planner is predictably stupid; structure complex multi-table predicates as joins (nested if necessary) rather than subqueries and it's almost imperative. Postgres OTOH is very unpredictable; sometimes it does the right thing, and sometimes it does something amazingly asinine, where simply swapping a table between from vs join clause can result in 1000x speedup. Specifically, I've seen pg take a query that looks like this: select ... from a join b join c join (select ...) d where a has millions of rows and is an equijoin with d where d has 10 rows, and it decides to materialize a x b x c, only joining in d at the last step. But do it like this: select ... from (select ...) d join a join b join c and it does the right thing! And analyze gets it right (i.e. the plan for the reordered joins is recognized as better) - never mind genetic optimization, it's lacking analytic optimization. With the lack of hints, almost the only tool you have to control query plans effectively in postgres is parenthesized joins. Since it's more liable to rewrite the query, the language ends up being less imperative, and thus less predictable. And I like predictability in production. SQL-level feature set is no comparison of course, pg wins easily.
  - davidgould 9y ago
    There are settings for choosing between the exhaustive search planner and the genetic planner. The exhaustive planner is better, but can be slow for complex queries with a lot of paths. But, if your query is at all time consuming you probably want to increase geqo_threshold and geqo_effort as well as join_collapse_limit and from_collapse_limit. I'd also suggest disabling nest_loop_entirely if you are having problems with bad cardinality estimates resulting in nestloop plans that run 100 times when the planner estimated once.

by seanot 9y ago

mgkimsal 9y ago

and how often do securities firms sue oracle, microsoft, ibm, sybase and other current and previous database giants?

nihonde 9y ago

Show me an enterprise DB license that offers you better indemnity/liability options than open source. (I negotiated them on behalf of huge clients for many years.)

rjzzleep 9y ago
It's not so much the license per se. It's that the setup is done by a third party that can be blamed when something goes wrong. I saw one one contract that was specifically saying that they are insured for 1 mio. in damages. The company for the longest time wouldn't even touch basic firewall rules without having the firewall contractor implement it.
- nihonde 9y ago
  This is so true, it hurts. I call it The Triangle Of CIO Turnover.

ballenf 9y ago

Nobody ever got fired for buying IBM. I think is the better point or rewording of your point.

vacri 9y ago
The state government of Queensland (Australia) has forbidden any further contracts going to IBM. https://www.itnews.com.au/news/queenslands-ibm-ban-lives-on-420969 https://www.itnews.com.au/news/queenslands-ibm-ban-lives-on-...

thisisit 9y ago

In my experience with couple of banks, it comes down to support. Lot of systems in banks are written for longevity. So they frown upon software which might be obsolete or people stop working on them 5 years down the line. A paid software, they reason, can at most release a new version while free might not provide enough incentive for people to work on it continuously. Many also think looking up issues on stackoverflow, google or blogs as unreliable. Then there are times when issues might be specific to installs or data, in which case sharing the logs/sample data (even masked ones) can be risky. They feel comfortable sharing logs/masked data with for example Oracle because they believe it to be safe and locked under Oracle's security guidelines. The 2nd refrain I hear is - security. In case of a major security issue being revealed, there is a general sense that FOSS will be slower to react in releasing a "stable" patch. Comparatively paid software take it as a reputation risk and work towards quickly releasing a "stable" patch. If people have to use FOSS, then they try and search for the paid support flavor. Recently we were looking at MQ software. When we zeroed in on RabbitMQ we were asked to deploy only the paid Pivotal version and not the free version because "support". Sure, these things might not be completely true but for many higher ups paying for something somehow makes them sleep better at night than a "free" alternative.

tajen 9y ago
This is wrong on so many levels, I suppose you mostly understand it, but here are the counter arguments: > Written for longevity OSS is much better at longevity than proprietary. Even if the authors all die without will, it is possible to fix the little bugs that prevent you from using the software on [NewTechnologyHere]. I've done it countless times with Java software; If anything OSS is the guarantee that you own your future and that the system will exist in the legacy. > Use paid flavor It's good, but what's better is joining the golf club of a principal maintainer. He's key in paying him to fix the issue you're having quickly and merging upstream.
- hindsightbias 9y ago
  Most enterprises don't want to own coders to fix/hack OSS. They want a solution, roadmap and 24x7 support.

mianos 9y ago

I spent 13 years writing the core trading system for many of the well known exchanges. We used open source wherever possible because the software tended to be more reliable. That said, clients usually got to request the database and we used Sybase a lot. I have been using Postgres for the last eight years since. every day of the week and I really like it but the planner is quite a bit worse than Oracle, SQL Server's. The postgres planner is still way way better than MySQL's. It still has correlated subqueries explode into cartesian joins. Mysql is great as a data store but it's more of a replacement for noSQL than an advanced query engine.

barrkel 9y ago
MySQL's planner is predictably stupid; structure complex multi-table predicates as joins (nested if necessary) rather than subqueries and it's almost imperative. Postgres OTOH is very unpredictable; sometimes it does the right thing, and sometimes it does something amazingly asinine, where simply swapping a table between from vs join clause can result in 1000x speedup. Specifically, I've seen pg take a query that looks like this: select ... from a join b join c join (select ...) d where a has millions of rows and is an equijoin with d where d has 10 rows, and it decides to materialize a x b x c, only joining in d at the last step. But do it like this: select ... from (select ...) d join a join b join c and it does the right thing! And analyze gets it right (i.e. the plan for the reordered joins is recognized as better) - never mind genetic optimization, it's lacking analytic optimization. With the lack of hints, almost the only tool you have to control query plans effectively in postgres is parenthesized joins. Since it's more liable to rewrite the query, the language ends up being less imperative, and thus less predictable. And I like predictability in production. SQL-level feature set is no comparison of course, pg wins easily.
- davidgould 9y ago
  There are settings for choosing between the exhaustive search planner and the genetic planner. The exhaustive planner is better, but can be slow for complex queries with a lot of paths. But, if your query is at all time consuming you probably want to increase geqo_threshold and geqo_effort as well as join_collapse_limit and from_collapse_limit. I'd also suggest disabling nest_loop_entirely if you are having problems with bad cardinality estimates resulting in nestloop plans that run 100 times when the planner estimated once.