Software companies around the world are joining individual programmers by entering the open source software arena. The business intelligence market is no exception.

OSS is computer software for which the source code and certain other rights are in the public domain, including rights that are normally reserved for copyright holders and provided under a software license. This permits users to use, change and improve the software, as well as redistribute it in modified or unmodified forms. Popular OSS camps include LAMP (Linux, Apache, MySQL and PHP), Microsoft .NET Framework and Java Enterprise Edition.

The other marker of OSS is that it is often developed in a public, collaborative manner. As such, it represents the spirit of democratization of software access and development.

While the open source idea has been part of the computing world for a very long time, it was not until 1998 that the open source initiative actually started. Still, many misperceptions continue to surround OSS (see Figure 1).

Because source code is freely available via self-service demo, trial and proof of concept, IT departments can get started right away. There is no need to wait for licensing, although you need to be aware of the license type to know what you can do with the software before you share your work with others. This might require a lengthy assessment process for some commercial software in order to understand complicated licensing.

“Good” versus “Bad” Software

When evaluating the software and the advantages of OSS or proprietary software, Instead of using labels such as “open” or “commercial,” it’s helpful to look at software based on requirements criteria (see Figure 2).

Benefits and Risks

There are both financial and nonfinancial benefits to OSS. OSS is usually strongly associated with cost savings; OSS alternatives that don’t offer a compelling cost savings component will likely face hurdles with enterprise IT buyers, who, outside of cost assessment, typically prefer to stay in familiar territory when selecting software - which OSS is not. Let’s take a look at the benefits and risks of opting for OSS:

Licensing savings: Small projects or revisions to existing open source projects won’t provide major savings in licensing. Money can be saved on licensing with new projects or on major growth of existing projects when additional options are needed as a result of scope creep, for example. But the focus of open source should not only be on licensing fees, because licenses are responsible for only a fraction of the cost of software over the lifetime of the project.

Flexibility: Most IT organizations that use OSS discover that the primary benefit of adopting it is not cost savings but flexibility. (Even when organizations do enter the OSS terrain with cost savings as the major decision factor, they often lack the tools or a formal method to calculate the expected savings.) OSS gives organizations the flexibility to try out various aspects of different software quickly and easily.

Technical support: OSS can reduce the cost of software ownership, but it is not free. It is a more practical choice when there is a large community of users. If developers can’t afford to maintain and support the open source software, then the cost savings of avoiding proprietary software licenses will be undermined by implementation costs. However, if there is a larger community, the cost of maintenance will decrease because there will be more people who can support it.

Software Maturity

It is imperative to find out who has taken the leadership position for developing and distributing the open source software. As with any software, it is important to know about the architecture, design, quality of code and how rigorous the testing is. Some other points to evaluate are:

  • Are there any conflicts with already established commercial software vendors?
  • Which products are bundled together?
  • How thorough is the documentation? (Remember that commercial software is in the same boat – most documentation makes more sense after you have found the solution to your problem!)
  • Is end-user support available? Is there an established developers’ community? (This is more important with OSS than commercial software.)
  • What support tools are available in the language(s) used in the organizations?

Skill Levels

Before adopting OSS, it is important to determine what skill levels are already available, what can be grown in-house and what will have to be bought.

OSS is not magic. There is no single button that makes the software run. Just like commercial licensed software, it requires configuration, installation, customization, integration, operation and maintenance. It may not be easy to find expertise in these areas for OSS, so you may need to cultivate your own. However, as OSS becomes more popular and training institutions encourage OSS, it will become easier to find qualified support services.

How OSS Vendors Make Money

It’s important to understand how the OSS vendors can survive without charging for licensing. Depending on the OSS vendor’s success, software vendors may embed popular or useful OSS products in their software. The OSS vendors can provide support to these independents at a cost.

Training, technical support (troubleshooting) and consulting support are also chargeable services. In addition, through the software as a service model, they can also charge for hosting and annual subscriptions, as well as for enhanced and extended versions of the free software. The software company Red Hat is a good example of this.

BI-Specific Concerns

There are many software types, systems, processes and capabilities needed in a full BI implementation.

  • Planning, designing and building the BI infrastructure. This includes compatibility with legacy systems, security and network requirements and evaluation of existing/future implementations and search capabilities for structured and unstructured data.
  • Designing, building and managing historical and operational information stores, particularly with regard to the DBMS, information and data modeling and metadata repository management.
  • Extract, transform and load considerations, especially data migration, BI querying and reporting, as well as with ERP, CRM, supply chain management and e-commerce.
  • Data visualization, prediction and presentation. This may include online analytical processing, querying and reporting, analyzing and forecasting and mobile applications.
  • Managing and enhancing BI applications and infrastructure. This includes systems usage and performance management, security and disaster recovery management, and capacity and performance management.

Additional BI issues are illustrated in Figure 3.


One of the most difficult challenges in adopting OSS is determining how various products can work with each other. While the open source development environment and infrastructure are used for open source applications’ development, they were not developed to work seamlessly together. IT must determine the following:

  • Is the application integration friendly?
  • Which other APIs and “bridges” are provided that can be integrated with the OSS software with some programming?
  • What is the maturity level of the application? This should be evaluated according to the particular needs of the enterprise. Solutions to software needs vary from person to person; independent research is necessary.
  • Another concern is determining how the commercial proprietary and OSS will coexist and prosper. As mentioned, the organization must understand and manage open source licensing issues, especially if the vendor company also distributes chargeable application software and/or proprietary source software. Will there be adequate support, maintenance services, documentation and user community for the open source software, and are all these resources available together? Management prefers to have a single “throat to choke” when things don’t work.
  • You should also make sure the software you are selecting has gone through “productization,” which can be analyzed with the following types of questions:
  • Which features are tested?
  • On which different platforms have these features been tested?
  • Are there installation scripts?
  • Have adapters to other programs, such as reporting software, been developed?
  • Is support for different databases and operating systems developed? Which ones?
  • Have graphical configuration tools been developed?
  • Which APIs are developed?
  • Which Web services are developed?
  • Is there engineering documentation?
  • Is there end-user documentation?
  • Which spoken languages are supported?

Additional challenges are illustrated in Figure 4.

Determining whether to use open source software in your BI implementation is a complex decision. But it’s time for organizations to get beyond the misperceptions and conduct a full study of the issues – and benefits – involved.

Editor's note: This is the sixth in a series of articles by Shaku Atre. Click on the titles to read the other recent articles: "Who in the World Uses Only Words and Numbers in Reports?"; ; "Who in the World Doesn't Want to Reach for the Clouds?"; "Who in the World Wouldn’t Want a Collaborative BI Architecture?"; "Who in the World Wants More Data?"; "Who in the World Needs a Data Warehouse?"; "Who in the World Wouldn’t Want to Evaluate BI Products?"; "Who in the World Needs a Hard Drive?"; and "Who in the World Wants to Just Be Structured?"

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access