Over a million developers have joined DZone.

Open Source BI vs Commercial BI part II

DZone's Guide to

Open Source BI vs Commercial BI part II

· Big Data Zone ·
Free Resource

The open source HPCC Systems platform is a proven, easy to use solution for managing data at scale. Visit our Easy Guide to learn more about this completely free platform, test drive some code in the online Playground, and get started today.

Well, it’s time to circle back into my five part series covering the differences between an Open Source business intelligence solution and a commercial business intelligence solution. There were some great points brought up in response to my last post found here: http://bit.ly/5WOUve that I would like to cover before I dive further into this discussion.

It was said in response to my article that “You don't have to pay money to use GPL software, but you can't do whatever you want with it, either. The license has some pretty specific restrictions.” What exactly does that mean? Do you really want to be able to modify an Open Source code and get stuck with the maintenance responsibility and ever increasing costs of merging foreign code bases to maintain future compatibility? Do you really want your engineering staff spending endless hours learning the code when they should be building your application? It is a typical “buy” versus “build” decision and I thought we crossed that bridge years ago.

With the source viewable and changeable, it is very tempting to spend time seeing how it works. Maybe you do want that responsibility so you have complete control over your application. In that case, the majority of the open source providers won’t offer you support beyond that point; making it very expensive if you hit any road bumps a long the way. Remember, this is software we are talking about…road bumps are inevitable. This, bring us to my next point. How do you move forward with choosing the right BI solution to implement? Do you select the software with a known quality and cost or do you choose the software that will allow you more customization?

In my previous article I compared the goals of the differing companies when creating their applications. From the beginning, commercial software is created to be a complete solution for its installed user base, and an open source application is created to be a “for developers by developers” solution. Therefore, you have to ask yourself, do you want to be in the BI tool development business and do you want to develop software (tools) without having total control of its road maps which is controlled by the Open Source company? I believe it comes down to your development capabilities, your budget and how much customization is required.

Which will have the lower total cost of ownership, and how do you gauge it? If you have any non-trivial Open Source custom feature to develop, that cost alone will most likely surpass the Commercial BI license cost. Even without custom development (then why you need the code anyway?), the TCO (total cost of ownership) of the open source application will cost more after the 3rd or 4th year. The reasoning behind this is that a closed source commercial software application will usually have a higher upfront cost for its licenses, while the open source GPL will be a less expensive initial cost.

Then you have your annual maintenance costs, the closed source maintenance costs are usually 40-60% cheaper than the commercial open source subscriptions. Now, let’s cut to the point, would you rather pay more upfront for a product that you know exactly what you’re getting and if something is missing, you can ask the vendor to provide it, or would you rather pay less upfront, but more over time for a product that you will have to maintain yourself once you customize it. Personally, in the BI space I’d rather let the software developers be software developers and know I’m paying for a quality application that will continue to be developed by purchasing the commercial BI software where their developers and support team know the product in and out without question.

That being said lets discuss risk. A commercial open source company needs to recover all their product development costs from the services and support revenue which may or may not be enough to sustain the continued development and maintenance of the product. In order for this business model to be successful they must have an enormous installed base. If that model fails, the venture capital funded Open Source company will have a very uncertain future.

This means more risk for their customers; the risk is especially high for companies that have gone through multiple rounds of venture capital investments. Open Source installs tend to fall into smaller deployments; they are rarely used in large scale implementations. This is because they are widely untested in large applications. I believe this is due to the maturity of the product, that an Open Source application ends up having the same if not higher TCO, and its potential to be risky from a business stand point in the stability of the Open Source software provider.

To dig a little deeper, I would think that 99% of companies do not want their engineers modifying the open source tools. Of course, that does not stop some individual engineers from making changes but for the most part no one modifies a commercial open source tool, only the GPL open source ones. Modifying these at all would render all support contracts from the vendor invalid. GPL Open Source has limited core functionality, so most likely the customer will need to modify the code and that effects the security and the timing of getting the application complete. For most of these GPL Open Source BI tools, security and performance are missing elements of the GPL core sources.

Usually not supporting clustering, connection pools and likely not having Page Level Security. When looking at this from a complete commercial source software standpoint, I believe they have a leg up. All of their engineers are in house and available on demand to create enhancements and solve the different business dilemmas according to their customers needs. Commercial Open Source vendors generally have a much smaller development group, mainly QA and integration engineers, while most major features are implemented by the Open Source community according to their needs. Which may not be the needs of the customer at hand, leaving the client to finish the application on their own.

It is also virtually impossible to predict timing of when someone in the Open Source community will pay attention to requests and do the work, often on a volunteer basis. Where, at a commercial software company the management team can turn the attention of a very large development organization to solve any issue required by the customer. I know I covered a lot today, but as I wrap up part two of this comparison of commercial/open source BI software and commercial BI software I am still convinced that in the big picture, the Commercial BI is still far superior.

Open Source software is great for small deployments, simple applications and in tactical short term solutions. I use Open Source software a lot, and on a lot of different levels. However, when this software is going to be effecting how I make my decisions on running my business, how I see my reports, and the security of my very valuable data, I am going to purchase the proven commercial BI software to do this for me. I’d love to hear input and arguments supporting commercial Open Source BI and GPL Open Source BI, because as of right now I am unconvinced of why I should recommend using an Open Core BI tool, or why I should purchase a subscription to get a Commercial Open Source supported tool where I can view the source code but not change it. Thanks for reading,

Ben Taylor Jinfonet Software

Managing data at scale doesn’t have to be hard. Find out how the completely free, open source HPCC Systems platform makes it easier to update, easier to program, easier to integrate data, and easier to manage clusters. Download and get started today.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}