Following up on a previous post, I wanted to dig a little deeper into the idea that database administrators have a higher resistance to open source in the database than programmers.

Searching the web,  I found very little on DBAs being either for or against open source.  I decided to call a couple with whom I’ve worked over the years.

First, I spoke with the most experienced DBA I know; he’s been at it longer than anyone I know.  He follows a very strict set of rules he’s developed over the years, but I’ve never seen him just say no to a new idea without a good reason.

I assumed he would be open but cautious towards open source.

Note to self: “Stop assuming.”

I explained what I was doing and asked how he felt about running open source PL/SQL in the database.  The first thing he said was, “I download all kinds of PL/SQL code.  I trust it, because I can go through it and verify it myself.”  He also said, “If I can see the source code, I don’t have a problem with it.”  He wants to be able to review anything that gets deployed to ‘his’ database

In his long career, the resistance he’s seen to open source has always come from management and/or the legal department.

He has seen the most resistance when he was working for companies who’s product was proprietary database software or companies with policies dictating that all software must have a license and a support contract.  When working at companies where the database was mostly used for internal applications, he’s tried to use open source whenever it was available.

Well, that was encouraging!

Next, I spoke with a person I worked with years ago who fits the stereotypical definition of a DBA.  He’s very focused, methodical and always keeps “his” databases running smoothly.

He told me that he never really thought about open source but added: “I often download snippets identified through online searches.”  We talked for a bit about different licenses and his opinion was always the same: as long as he can review the code before he installs it, that’s fine. Open source vs. proprietary doesn’t matter so much, assuming the specific license works for the project.

Even more encouraging!

Finally, I spoke with a friend who does a little bit of everything.  He’s been a system admin, a DBA, and a developer.  He is constantly exploring new technologies and programming languages.  We’ve had many discussions about open source, so I know he’s not against open source in any environment.  I asked him about the resistance he’s encountered when trying to use open source.

He said,  “The company environment/policy would determine whether or not I would run OS in the database.  If we’re developing a closed source product, we wouldn’t want to include open source that had license terms that require us to open source our software.”

He told me about a coworker who had been “burned by a restrictive open source license on products that he’d used before.”  Basically he had included some open source components in a proprietary application, and had not read the license carefully.  That license required them to open source the company’s product, which of course was not an option.  He had to remove those components and build his own.

Clearly, if and when you are going to incorporate open source code (or any code you don’t own), you’ve got avoid making assumptions, and perform due diligence on the licensing side of things.

Common threads

While I realize that a sample count of three is not sufficient to draw a solid conclusion, common themes were clear:

• When installing code in the database, regardless of origin, DBAs want to be able to review the code.  It doesn’t matter if the code is open source, proprietary or internally developed. “Trust but verify” always applies.
• Company management tends to be more concerned with the open source label than the people who work with the code.
• The actual license terms matter, not the fact that it’s open source or proprietary.  There are many different types of each.

Thought experiment

Suppose….

• We are looking for a PL/SQL package to solve a problem in our application and we find two that should work. One is open source, the other is proprietary and its code is wrapped.
• Both come from reputable companies.
• Both licenses allow us to use the software without restrictions.
• The open source package has an active user community with frequent commits to the project.
• The proprietary software has good documentation and is updated regularly.
• Company management will approve either choice.
• Both are free.

Which would you recommend to company management to use, and why?