Matt Dugan Makes Case for Enterprise Open Source

There was nothing new in what Matt Dugan said. There were no ground breaking revelations. He just methodically made his case, point by point, explaining why open source was usually, if not always, the best solution for business.

To me, this was just what the doctor ordered. I’d just sat through a forty-five minute lecture in that very same room from an open core guy that had left me fearing that enterprise open source companies were just as greedy and potentially as unethical as the proprietary guys. Dugan fixed that and quickly reaffirmed my faith in the notion that open source is where the good guys live.

The venue was the inaugural All Things Open conference in Raleigh. Dugan was representing Shadow-Soft, which helps companies find and deploy open source solutions. The workshop was called “In Defense of Vendor Mistrust–The Importance of Selecting Open Source Solutions for Your Business Needs.” The talk was aimed both at IT managers needing ammunition to convince hooked-on-proprietary bosses of a better way and at front office types as an antidote to the FUD they’d swallowed whole.

Nature had called and I returned to the room a little late. Dugan was talking about the common practice within some IT departments to “borrow” open source code to integrate within internally developed applications.

“If you’ve worked in the non-open source sector for any amount of time, the vast majority of the things that you build internally are using open source stuff. You’re just not releasing it back, and those companies are not releasing it back, because they don’t really embrace that same kind of model. They treat open source as it’s just free stuff. I go out and download it, I use it in my data center and I’m happy to do that. So it’s like free beer.”

Most of his talk was on how to decide what software project or vendor to choose, and he pulled no punches in explaining some of the tricks up proprietary vendors sleeves, contrasting that with how situations are handled within most open source projects.

“If I’m a business and I’m getting something on a contract or license from a vendor, well then, a vendor’s a vendor to me, right? Procurement says, why should I care? I just want whatever I can get for as cheaply as I can get it.

“But you have to come back into a metric based analysis of your decision. What’s the real mean time to resolution of a bug report? If you open a support ticket is it responded to immediately by an automated system saying thank you for your bug ticket? Well, guess what? They just met their one minute SLA. You’ve now received a response, it’s just not useful to you.

“You have to look at what it really takes to turn that around and get back to you. Is the focus to ship and sell, or is it to focus on the quality of delivery? One of the things we talk about in open source a lot is that it’s a meritocracy, which means that your value is determined by how good you are at what you do and the quality of what you do.

“How were the last few major defects resolved?

“Something broke. Was it fixed right away? Was it fixed after a press release came out about it, or a news article came out saying this is terrible? Was if fixed after there was attention given to the vendor, attention given to the project, or was it just fixed?… Here’s a newsletter or here’s a forum post or usenet post, there’s this giant bug, it’s fixed now, please, everyone update to the next point release.”

One of the problems with buying proprietary software is that often you don’t really know what you’re buying. You only know what the vendor says you’re buying. Not only do you not know if an application will meet your needs, you know nothing of the quality of the code itself.

“Another part of the difference in proprietary and open source is really knowing what you’re buying. If you’re saying, I want a house on the hill, your mental picture is a chalet in the mountains, right, and a waterfront view. What you might be buying, at that price, is a lopsided chicken coop. It’s just something put together and sold to you in a nice package but because you don’t really see how it’s built and how it’s constructed, all you get to see is maybe a functional POC [proof of concept] that kept this test subject dry when it rained…

“There are things that happen underneath the covers and if you ever worked for a vendor that deals with proprietary software, deals with intellectual property…, then you know how quickly POCs become production, how quickly POCs become product. And oftentimes they’re just simply not ready. They’re not vetted. They haven’t had enough users. They haven’t had enough real focus on the development quality assurance of that software. Maybe the features function, but is it really going to be the kind of thing you want over the long term?”

Again, if you’re reading this on FOSS Force, chances are that none of this is new to you. Indeed, I doubt that this was news to anyone in the audience at All Things Open. But it’s all stuff that needs to be said again and again, because sometimes we get so busy remembering what’s important to us that we forget what might be important to others. Like access to the source code, which almost never exists with a proprietary product.

“You have no direct ability to correct change. You can request changes from your vendor. They might integrate it into a new future release. They might release a one off patch just for you. Well, guess what, you’re now your own special and unique snowflake in their world and that locks you in even further.

“In open source, not only can you make direct changes into the code, you can have long term influence, which means that you can start to drive the direction of that project. Just by the fact of you contributing or your company’s making any sort of sizable source code contribution in that project, that project itself gains more critical mass and will start to move forward.

“Vendors resolve defects; you make workarounds.

“The opposite is true in open source. You might come up with a work-around, but you can directly resolve that defect and you can interact with the community to resolve that defect. That community is going to be much more interested in making sure the defect is resolved as a whole rather than as a patch that maybe you get as part of your upstream to that proprietary tree.”

All of this is, of course, only a small part of Mr. Dugan’s presentation, which concluded with a long and energetic question and answer period.

As I left the lecture, it occured to me that if had a boss who was insisting on buying some awful and expensive proprietary stack, I’d try to get Matt Dugan on the phone to talk to him.