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.
But I just cant stand the loving hype for MS here. They gave out such horrible and dog slow drivers to their paying customers that people reverse engineered the protocol and wrote their own. And it still performs very well.
Now that MS publishes this codebase (which should have been standard, or at least best, practice), they get showered with love.
Like an abusive relationship where one is happy and extatic if the abuser is reasonably nice for a day.
I just had a quick look at the code and the code quality leaves a lot to be desired. If internal quality is an indicator for external quality there is indeed a lot of room for improvement left.
While Microsoft claims the new driver is fully JDBC 4.1 compliant key JDBC 4.1 methods throw SQLFeatureNotSupportedException and the code is littered with comments
// The driver currently does not implement JDDBC 4.1 APIs
Recently I had an issue with connection timeouts in my connection pool when using the jTDS driver to connect to the Azure SQL Server service. When I switched to Microsofts updated JDBC driver, that problem was solved immediately.
As if the fact that jTDS is mostly unmaintained wasn't enough reason not to use it, the MS driver supports several extra useful features e.g. bulk insert and availability groups (for AlwaysOn)
Nice. Microsoft seems to be open-sourcing a fair bit of stuff lately.
However, unlike their other repos there are a couple of things that strike out. The code isn't even consistently formatted. There are parts that make you say ouch.
How did people use this before if it wasn't in the Maven Central Repo?
I know it's possible to not use mvn, just wondering what people did in cases like this where a possibly major component in the stack was unavailable. Most big stuff in Java can be found in mvn, and if not we often end up using an alternative. But that's not so easy for a driver.
Short of having a common / private repo (which is good advice for many other reasons), you can add it directly to the project so that it comes bundled with your source. This has the disadvantage of adding the JAR files to your source (which fattens things) but it has the advantage of working out of the box without any special config on a new developer's machine.
I have similar library and I use the following approach. I have "lib" directory in the project and I have those jar files there. Also there's simple install.sh script which calls "mvn install:install-file" for every jar-file. So developer has to run install.sh script once and he's done.
Yep, same. For artifacts I've dealt with before it is semi-automated; it infers the groupid-artifactid-version from the name of the file downloaded from the vendor site.
In my case, I'm only using Oracle from a (Java) web app, so I just put the driver directly into the JBoss (JEE server brand of the day) container setup, rather than something else in the Maven build.
The driver is only needed at run time, not compile time, at least in this case.
Microsoft has been open-sourcing a lot lately, but it seems to be mostly "peripheral" software...
The JDBC driver can be used to connect to SQL anywhere. Use it to connect to SQL Server (on-prem or in the cloud), Azure SQL Database, and Azure SQL Data Warehouse.
...associated with the use of their commercial products.
http://microsoft.github.io is a metasite with links to most of the Microsoft GitHub organizations and repositories. You can spend days flipping through all of it.
Same as everyone? Did you see Google open-sourcing their search engine? Or "only" libraries? I am rather happy to see some parts of Microsofts software stack open source than nothing.
The value of Google software is not in the software itself, but also in the data. Without it, running Google search software on your hardware would get you nothing.
I remember we had once revert to java 6, because we couldn't get connectivity in Java 7 with SQL Server through their JDBC Driver... It took days to figure it out...
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.