Skip to main content

Open source as an affordable key to innovation In Enterprise Architecture

The case for open-source software

In pursuing growth and success, companies constantly search for tools to improve operations, manage change, pare expenses, and deliver value to customers. Many times, the right tool is software — an application or a suite of programs that, over time, help a company decrease costs, enhance the quality of goods and services, save time, increase automation, or improve key business processes.

Until recently, companies were forced to look to the commercial software market for these tools. These proprietary applications can be costly, and often include extraneous features that companies don’t need.

Today, open-source software provides a viable alternative to many commercial applications. Open-source software is noncommercial software — typically offered free or at low cost — developed programmers and companies that collaborate, contribute to, review, and improve each other’s work, under the oversight of governing boards. These products are easily downloadable or can be obtained in many standard media formats at a low cost.

Innovation without breaking the bank

Companies usually begin exploring open source options because of cost. And while low cost is indeed one of the most attractive features of open source software, additional benefits of open source adoption may mean that a company can:

  • Provide low-cost or free alternatives to commercial products
  • Adopt new or emerging technologies without making a substantial investment
  • Improve, enhance, expand, or modernize IT systems without acquiring or upgrading commercial products
  • Explore and test new technologies that could be implemented later, either with an open-source or commercial solution

Open-source software provides companies with opportunities to do more than save money. Many leading companies have embraced open source initiatives to drive innovation. Because the underlying programming code for open source software is open and available to all, companies can be more than users of open source software — they can take an active role in modifying and developing applications and sharing improvements with the open-source community. Taking such an active role can form the framework for revenue-generating activity within your company’s IT organization. And because open source software requires little or no capital investment, it allows companies to adopt emerging technologies and test them before making a significant financial commitment.

What is open-source software?

Open source software Description Commercial alternative
Apache HTTP web server Oracle WebLogic server
Mozilla Firefox Web browser Microsoft Internet Explorer, Safari, Chrome
OpenOffice Office productivity suite Microsoft Office
Compiere Enterprise resource planning and customer relationship management AP Business All-in-One, SAP Business ByDesign, Oracle E-Business Suite, Microsoft Dynamics
Alfresco Content management system EMC Documentum
JBoss ESB and JBPM Middleware and business process modeling Software AG’s Webmethods, Tibco ESB, IBM Websphere

drive to develop open-source software was fueled by the desire for more technological innovation — a desire that continues to attract innovators from around the world. Many open source pioneers were Fortune 1000 company developers, graduate students, teachers, and researchers who grew frustrated with the existing products available to their organizations and sought to create alternatives.

Although open-source software is often either free or available for donation, it should not be confused with freeware and shareware. The defining characteristic of open source software is that it is available for continuous modification and improvement by any network of developers, who collaborate to review and build on each other’s work. Advocates say the open-source model fosters quality assurance, higher reliability, greater flexibility, lower costs, and less reliance on the proprietary standards designed by commercial vendors. The Open Source Initiative is the primary support and advocacy group.

Many of the websites and services we use today — including many social networking websites — use open-source software. Many people in your company may already be familiar with some of these popular open-source applications

Open source: part of the big picture for IT transformation

Open-source software can be part of a broader shift for your organization — one that helps transform IT from a cost center to a revenue generator and reduces expenses. Your company can make open-source software part of the strategy to introduce your organization to cloud computing, software as a service, infrastructure as a service, and greater use of server virtualization. These changes can help you reshape your IT organization around innovation through solution modeling, and a greater focus on business objectives, process improvement, operational predictability, and preventive maintenance. As a result, your IT organization may be able to reduce operating costs, improve agility, and provide more responsive service to clients. These improvements may also open opportunities to provide service and create products that can generate revenue and introduce game-changing innovations.

Overcoming hurdles

Reticence to adopt open source

Several years ago, legal questions arose that stymied the wide-scale adoption of open-source software.

In the early to mid-2000s, a series of legal challenges against Linux, the popular open-source operating system, deterred many companies from considering open-source alternatives. In a landmark case, SCO Group, a successor to one of the original UNIX operating system vendors, the Santa Cruz Operation, claimed that Linux contained UNIX source code. SCO Group sued IBM, a Linux user, for $1 billion, and demanded that all Linux users pay license fees. A flurry of related lawsuits and countersuits followed.

This case and the legal turmoil that followed understandably alarmed Linux users and the broader open-source software community. However, concerns that open-source software would expose companies to greater risks of lawsuits have since dissipated. Many of the earlier suits were dismissed, and the legal actions did little to deter the development of open-source software or adoption by enterprise users over the long term.

Companies may also hesitate to adopt open-source software out of concerns about the broad cultural change such a transition might entail. For example, many IT workers, who already have a high degree of comfort with commercial software applications, may resist open source alternatives because:

  • It could impair long-established relationships with contacts at commercial software partners
  • It may require updating or replacing files and databases, especially if the current commercial software uses proprietary formats
  • It may diminish their experience with known platforms and or applications

The experienced staff has traditionally been more reluctant to move from commercial software to open-source software. They may feel threatened, in fact, by a loss of expertise. Your company should explain clearly the benefits of open source software to these workers, re-enforce the value of market relevance, and provide training and change management to help with the transition. Remember that these change issues are not unique to open-source software. Organizations will often face the same obstacles when moving from one commercial application to another.

It is also important to keep in mind that the rising crop of developers, software engineers, and programmers who likely already work in your organization will need no introduction to open-source software. College campuses today are fertile ground for open source development and implementation, so recent graduates come to the workplace with a clear understanding of the open-source and its challenges and rewards. With such a high level of comfort with the open-source paradigm, they will usually welcome the opportunity to bring open source applications into the enterprise.

In many regards, the management and support of open-source software should not vary greatly from that for commercial and custom software.

Understanding new licensing models

Despite the open and readily accessible nature of the software, there are still licensing considerations when moving to open source. However, the licensing paradigm differs significantly from commercial applications. Operating requirements, language, support, and maintenance specifications related to open source licenses are generally very different from those of traditional commercial licenses, which carry implications for terms for use, distribution, and what sort of commercial and open-source works can be derived. Figure 1 describes the two most common types of open source licenses, the general public license (GPL) and lesser general public license (LGPL).

General public license (GPL) A software license issued by the Free Software Foundation (FSF) providing that anyone distributing a compiled program that is licensed under the GPL must also provide source code, and is free to make modifications to the program as long as the source code for those modifications is also made available
Lesser general public license (LGPL) Allows linking of free software with commercial software. Originally called the GNU library general public license, it is generally held that a LGPL offers less protection of the user’s rights than the GPL.

Taking the first steps toward open-source software

Consider deploying open-source software in the back-office first

While open-source software provides alternatives to nearly every kind of commercial software, most companies will probably look first for open source solutions for back-office applications. This is because back-office applications, unlike client- or customer-facing applications, are typically deployed in a controlled environment. As they are implemented for small groups of employees or business units, they typically require a smaller investment in training than an enterprise-wide application and reduce risks associated with mistaken use or misinterpretation. Also, the back-office environment can often serve as a petri dish for the IT department to understand enterprise deployment implications: new applications can be tested and deployed quickly, and training, when necessary, need only involve a subset of employees rather than the entire workforce.

By first focusing on open source applications for back-office functions, companies can develop and refine organizational infrastructure and institutional knowledge to support their open source initiatives. If issues arise during these back-office pilots, public- and client-facing systems should not be affected.

What kind of open source user will your company be?

Companies will need to determine if they will be using open source software "as is," or if they will be modifying and customizing it or integrating it into a software product or service for distribution to customers or clients. Figure 2 describes the differences between open source users, creators, and modifiers.

Users Users face limited risk and receive many benefits. Generally, users can use the software but cannot modify it. The license on some open-source products does not allow the user to make a profit or charge a fee for using the application. In many cases, using these programs in a corporate setting is not considered a violation of the license. If your internal IT department uses a chargeback model for shared services, it may be beneficial to obtain professional advice before using such an open-source product.
LCreators and modifiers Creators and modifiers must register with the open-source community for the application. The community will explain the guidelines and rights pertaining to modifications of existing products. In general, you should expect to track all modifications and submit those changes to the community.

It is important to remember that participation in an open-source community as a creator or modifier requires a significant commitment of time and resources. The open-source community contracts will require you to track changes, even at the embedded subcomponent layer. In instances where individuals or teams edit the open-source software independently, manual tracking of these changes can become extremely challenging. However, there are several commercially available tracking and identification applications that automate these processes. The use of such software can reduce the risk of failing to disclose modifications to the open-source community.

A road map to adoption

Realize that, like any commercial software, open-source software should fall under the oversight of your general software governance framework. Consider open-source applications as part of a greater initiative to analyze all of the software your company presently uses. Such a rationalization exercise can help identify inefficient or duplicative software usage. Eliminating or replacing commercial or legacy applications can significantly help your company save money and implement improvements.

Create a strategic plan for the adoption of open-source software, including timetables, staffing needs, and maintenance budgets. Identify and prioritize the processes that can benefit from open-source software. Discuss future plans, support, maintenance, security, and upgrade needs.

It is also important to understand that the number of available open-source software options is growing rapidly and that they encompass an enormous selection of applications and functions. Some are incredibly robust and mature enterprise applications, while others are unstable, poorly designed, poorly supported programs. Accordingly, it is critical for companies to take a methodical approach to select open-source applications. And any open source software should be rigorously tested before it is integrated into the enterprise environment.

Consider the following steps as your organization establishes a framework for integrating open-source software:

  • Assign your enterprise architecture office the responsibility of overseeing and managing open source adoption. If your organization does not have an enterprise architecture office, or the office does not have the capability to handle these responsibilities, create a task force to oversee and manage open source adoption.
  • Establish clear parameters for initial open-source projects. They should be small-scale applications that require little or no investment. The software should be structured in a way that allows your organization to fully explore its functionality so you can best understand the product’s capabilities and whether your firm will be a user or an active contributor to the community. These initial open-source projects should help the organization understand licensing and application selection issues for larger, more extensive projects in the future.
  • Develop a formal review process for open source software and vendors.

Questions to consider when evaluating open source software

Your company should consider establishing a formal review process for open source software and vendors. Consider these questions when evaluating software:

  • What are the name and version number of the open-source program?
  • What is the full legal name of the open-source community?
  • Is the software covered by an open-source license, a proprietary license, or both?
  • What kind of license (GPL or LGPL) applies to the software?
  • Does the source code of the open-source program internally reference other applicable licenses?
  • Do you know whether the open-source program is, or ever has been, subject to legal dispute?
  • Is the development company or the open-source community subject to legal dispute? Has it ever been?
  • Do you know whether any patents cover, or have been claimed to cover the open-source program?
  • Has any person, company, organization, institution, or other entity ever claimed the open-source program infringes upon or violates its copyrights, patent rights, or any other rights?
  • If you use a particular open-source application, are the files, libraries, documents, or other works you create or modify covered by the GPL, LGPL, or other open-source licenses? If so, how does the license extend to these files?
  • What use of, or access to, libraries or files within the open-source software is needed for the standard use of the product? Are these files or libraries covered by the GPL, the LGPL, or another open source license? How does a particular license attach to a particular file or library?
  • Does any application running on the open-source product communicate through sockets, pipes, command-line argument, or application programming interface to the open-source product?

As a user of the open-source product, will you be required to use or access data structure layouts, inline functions, or macros from an open-source library or other open-source programs? If so, which open source license attaches to which library?

Communicate and interact with the enterprise and capture and share knowledge

Once your framework is established, your company should develop and implement a training policy for open-source processes. Create an internal website for open-source processes and governance. Also, educate the enterprise on the strategy and cost benefits of adopting open source and describe its direct budgetary impact on each business unit.

You should also create a formal knowledge-sharing process so that lessons learned from initial open-source projects can be applied to other projects. Be sure to research open-source practices at leading organizations.

Comply with open source licenses

Make sure your company fully catalogs all of the programs it uses and complies with all the licensing rules. Inventory all current uses of open source software, including products licensed from third parties that contain open-source software. Also, prohibit the use of open-source software source code that has been modified from base code, as first licensed.

Your company may consider using a tracking application to monitor your open source development. Several programs, including commercial ones, are available for this task.

Manage risk

Your company can take steps to help mitigate risks that may arise from using open-source software. Many of these practices can also apply to managing risk for commercial software:

  • Prohibit unlicensed open source modifications and distribution.
  • Determine if there are any pending legal claims against the software before using it. If there are pending legal claims, discuss them with all stakeholders.
  • Develop a list of preapproved open source applications that can be used by your company without legal review.
  • Include open source activities in your IT audit process.
  • Include open-source software due to diligence processes for any merger and acquisition or joint venture activities.
  • Obtain legal review and approval of all open source licenses.
  • Consider prohibiting all open source software with a GPL that requires you to submit any of your changes and contributions to the open-source community.

Create guidelines for communication with the open-source community

Create formal guidelines for employees to interact with the open-source community. As a part of this process, determine whether to allow employees to interact directly with the open-source community, with a suggested bug fix or upgrade, for example, or restrict these activities to the IT organization. You will also need to decide if it would be preferable for your organization to remain anonymous in its interactions with the open-source community.

In order to maintain strict compliance with licenses, your company should establish rules for employees using open source software, including consequences for those who violate licenses. You should train employees to use the software properly, and make sure they understand the consequences of misusing applications or violating licenses.

What this means for your company

Companies interested in saving money and leading in innovation should initially consider open source alternatives to commercial software. The transition to open-source software clearly presents some challenges — from internal cultural change management to understanding new licensing models and guidelines for application management. But once you have cleared these obstacles, integrating open source software presents technological opportunities and returns on investment rarely possible with commercial software.

Let’s engage