Having dealt with many database drivers over the years, I can say first hand that closed source drivers are the bane of my existence. The only thing worse than running into a deep-in-the-stack bug in a database driver is one that you can't correct, let alone debug properly.
Regardless of your views on closed source software on the server side of things, it's a disservice to your customers to not have open source client side drivers. The secret sauce is always on the server side so it doesn't buy you anything. At best there's (very poor) argument for security through obscurity or you're doing something silly like hiding server side features behind client side feature flags.
Plus the more tech savvy of your users will directly contribute back to improve the driver. This is both for fixing existing bugs and adding features to support existing database server features. In this particular case, I've got a laundry list of things I'd like corrected / added / improved in the SQL Server JDBC driver. Had it been open sourced a few years back, I would have already done them myself.
Unless there's a legal restriction for not doing so, like say not owning the original source, there's no good reason not to open source the client side of things.
This reminds me far too much of the .NET DB2 drivers. What a steaming pile, not to mention having to navigate the labyrinth of the IBM download site to even find it in the first place.
You know what's worse? DB2 for iSeries. Pisses me off to no end that pulling JTOpen from Maven is crazy easy, but if you want to access your data from any other language prepare to shell out thousands of dollars for "DB2 Connect" (per server!) because it's totally incomprehensible that even though you've already payed through the nose for IBM i that you shouldn't be charged for accessing the data anywhere else.
"Hi $BIG_COMPANY, we'd like to expand our usage of $SOFTWARE that we've already got a $BIG_MONEY license for. Where can we get client drivers for a new app that will use it?"
"Hi $CUSTOMER, that's great news. Send us a check for $MORE_MONEY and we'd be happy to help."
"Hi $BIG_COMPANY, to clarify, we're already paying $BIG_MONEY for a license for the server and we'd like to expand our usage of it. That means in the longer term we'd be more entrenched into using it and would likely renew your contract."
"Hi $CUSTOMER, that's great news. Send us a check for $MORE_MONEY and we'd be happy to help."
Thank you. I will now need several hours of therapy to get quality sleep again.
Porting a .NET application build for MS SQL to DB2 and dealing with all the ... pecualiarities of the DB2 driver is something I will hopefully never have to do again.
Having dealt with many database drivers over the years, I can say first hand that closed source drivers are the bane of my existence. The only thing worse than running into a deep-in-the-stack bug in a database driver is one that you can't correct, let alone debug properly.
Regardless of your views on closed source software on the server side of things, it's a disservice to your customers to not have open source client side drivers. The secret sauce is always on the server side so it doesn't buy you anything. At best there's (very poor) argument for security through obscurity or you're doing something silly like hiding server side features behind client side feature flags.
Plus the more tech savvy of your users will directly contribute back to improve the driver. This is both for fixing existing bugs and adding features to support existing database server features. In this particular case, I've got a laundry list of things I'd like corrected / added / improved in the SQL Server JDBC driver. Had it been open sourced a few years back, I would have already done them myself.
Unless there's a legal restriction for not doing so, like say not owning the original source, there's no good reason not to open source the client side of things.