Open-source software is here, and it's a good thing. But like TV dinners, what you find under the cellophane wrapper may be an unpleasant surprise. Corporations are increasingly tempted today to embrace the open-source paradigm, but the risks and pitfalls should be carefully examined before beginning an implementation project using unexamined open-source applications. This article examines some of those risks and suggests ways to work around the pitfalls, using a case study of a popular CMS.

Open Source: A Means to an End

Software products that would today be marketed as "open-source" have been around since the 1960s, but the common use of the term in 2007 usually describes three things about any particular open-source application:

• The availability of the application's source code itself
• The way the software was authored
• The way the software is licensed

From a CFO's perspective, the advantages of obtaining an open-source application may seem almost limitless. First, there is the cost factor. Most open-source applications are licensed through one or more of the 60 open-source licenses that are currently approved by the Open Source Initiative. These licenses are usually free or inexpensively priced, but each has unique requirements that should be studied.

For instance, the GNU General Public License (GNU GPL or simply GPL) is a widely used free-software license, originally written by Richard Stallman for the GNU project. It defines how the software is to be distributed and how authorship is to be noted, and it releases those authors from their rights to be compensated. Other open-source licenses may be less generous and have specific requirements that must be met before they are used for commercial purposes.

Shared-source licenses, such as the Microsoft Permissive License (MS-PL) and Microsoft Community License (MS-CL), have some similarities to open source.

Yet, for the CFO looking for an inexpensive solution to a pressing business need, browsing through catalogs of open-source packages that are available on the Internet often makes the idea of filling the application gap with an open-source package seem like a no-brainer.

But the most important thing for that CFO to understand is that open source is a means to an end, but too often it is not the end itself. Once the software is obtained, it must still be configured and customized to the specific needs of the business, and this can be a daunting and expensive process.

An Example of Open-Source Implementation

Let's take a look at a recent experience of a company that wanted to use the open-source Joomla content management system (CMS).

Joomla is a free, award-winning open-source CMS written with PHP for publishing content on the Web and intranets, using the MySQL database. Joomla includes some exceptionally powerful features, such as page caching, RSS feeds, printable versions of pages, news flashes, blogs, polls, Web site searching, and language internationalization. It's licensed under the GPL. Literally thousands of Web sites use Joomla today, and thousands of developers have built extensions and plug-ins to increase the base power of the system.

IT Decision-Tree

The decision-tree that prompted the IT department to recommend Joomla to management was fairly straightforward:

1. Joomla meets the basic requirements of the company's Web site.
2. Joomla is stable.
3. Joomla is cross-platform, using PHP and MySQL, and can run on any of the company's servers, including the company's System i.
4. Joomla has a large user-support community with many developers of extensions and plug-ins (both commercial and free).
5. Joomla is open source, making it possible to alter or customize its base functions to meet the specific business needs of the organization.
6. Joomla is free.

The Comparison with the Package Environment

The logic of using Joomla was made ever more tempting because the company had thoroughly investigated commercially available CMS packages that cost between $10K and $60K. And when customization costs of those packages to meet the specific needs of the organization were explored, the overall implementation costs blossomed to over $120K.

The CFO and the IT manager looked at the comparative costs and decided that it was worth the effort to explore the Joomla environment. IT obtained Joomla from the Internet and, in the space of a few hours, had the package installed on the company's test server. IT then began the process of building a mock-up of the desired business Web site.

Templates

The first thing management needed was a Web site that uniquely branded the organization. Joomla came with two basic templates that did not meet those branding needs, so IT began looking through the hundreds of free templates that were available from a slew of Joomla support sites. Each candidate was downloaded, easily installed, and inspected, but still management was not impressed.

Finally, IT purchased a subscription to a commercial Joomla template site that provided a catalog of several hundred templates that looked promising. The cost of this subscription for three months was $50. IT chose a template that most closely matched the visual functionality of what its management desired and deferred customizing the template to a later time. The amount of time researching and obtaining that workaround was about a week.

Plug-ins

Some key site requirements were missing from the base Joomla package, such as the ability to collect expanded registered user information, develop a company product catalog, and manage some unique workflow issues for registered users. So, once again, IT looked on the Joomla support sites for plug-ins that would span the gap. And, generally speaking, it found nearly everything it needed. One component handled the registered user information, one offered a product catalog, and several others promised to solve the problems of workflow. Most of these were free GPL components, modules, or macros, and the most expensive was a stunningly cheap $70.

Integration

Nearly all of the templates, modules, components, plug-ins, and macros integrated relatively well with the basic Joomla package. But here IT began running into problems that started to chew up the hours.

• Each Joomla extension had a similar—but slightly different—interface, complicating how the various pieces functioned together. Not all of these interfaces integrated with the main Joomla menu system, making it even more complicated to understand how they worked.
• Some Joomla extensions worked well with other extensions, but others did not, delivering illogical results that began frustrating the implementers.
• The level of help documentation for each extension ranged widely, from full PDF manuals to one-line descriptions contained in the extension itself.
• Support from the authors of the extensions was entirely based upon Web site Q&A, forums, FAQs, or email tickets, delaying the integration processes and slowing the implementation of the mock-up.
• Specific features that were described in a free extension were sometimes crippled by the author of the extension, who offered a "commercial" version that worked better.

Crazy Quilt of Functionality

The results of integrating the extensions to the basic Joomla package resembled a crazy quilt of functionality for the back-end administrator. The steps to enable or publish one piece of content through one extension were different than those required for another. The back-end quilt pieces required considerable experience with each module to understand how the actual content would be displayed on the site, making the mock-up sometimes look unprofessional. This frustrated the implementers. Still, IT persisted, pouring more hours into the mock-up.

Mock-up Completion

Nonetheless, the overall functionality of the site met the requirements that management had in mind. Moreover, IT had reached the end-point of its ability to customize without digging into the underlying code that it had obtained through the open-source licenses.

"If management can accept the mock-up," IT ruminated, "then we can further customize and integrate by using a consultant who is familiar with Joomla and PHP."

This left only three unanswered questions:

• How would IT migrate the thousands of pages currently maintained on the company's public Web site along with the user base of registered users?
• How would IT streamline the workflow so that the Joomla CMS system could be turned over to users?
• How would IT train the users to use the resulting system?

Migration

IT soon discovered that the only way to migrate current users and data—as well as previously composed content—from the old site was to hire a consultant. Importing data into the underlying MySQL database structure was undocumented and would require experience that could be obtained only through a consultant. The estimated cost of these consultants ranged from $55 to $120 per hour, and finding the consultant who had knowledge of both the source and the target systems was a challenge.

The required custom PHP code was spec'd out, and the overall cost estimate came in at about 80 hours of work. (IT had looked into available plug-ins for Joomla that promised some functionality and decided these would speed, but not supplant, the need for a consultant.)

Workflow Integration

The next estimate was to identify the cost of streamlining the workflow processes so that maintaining the CMS could be turned over to the users. IT realized that each extension needed to be examined by a PHP professional and modified to meet the requirements of workflow integration. IT had used 30 open-source extensions in the mock-up, so they estimated another 20 hours effort per extension as a ballpark figure.

However, one of the key extensions that IT had purchased was not an open-source component, but a commercial add-in that required IT to estimate at the going work rates of the extension authors. These rates ran as much as $300 per hour, making the estimated cost of that one extension skyrocket to $3,000.

Guns for Hire

This is not an unusual occurrence in the open-source world: Authors who build free or inexpensive extensions make their money on the consulting modification fees that result from the open-source platform. While this is, in most cases, acceptable—considering that the original cost of the package is so low—the downside is that IT must wait for the availability of the consultant, who is often quite busy making a living modifying code for his other customers.

Nonetheless, the overall estimated costs of the entire set of modifications came out to be between $5,000 and $15,000. This included customizing the CSS and HTML template for the Web site display, modifying and integrating extensions to work together more seamlessly, and building a migration path for content and users from the old Web site.

It did not include training the users, which would fall on the shoulders of the IT department, which had pulled the project together from the various open-source pieces.

Is It Worth It? The ROI Question

When IT presented the overall scope of the project to management, the CFO asked, "Is this worth the effort and the cost?"

The costs of the commercial software packages that were competing against the Joomla open-source package were between $10K and $60K, offering support, training, and out-of-the-box functionality that was integrated. Further proposed customization pushed the overall figure to the $120K mark, but it promised single-point support through the entire process.

By comparison, the Joomla Open-source solution started at $0 and escalated to between $5K and $15K without external commercial support, without integrated documentation, and without training. Plus, monitoring and managing the completion of the project would consume internal IT resources for many weeks.

Finally, if future releases of the base Joomla package or the various extensions were implemented, could IT be responsible to re-create the modifications that had been previously made by the consultants?

In other words, did going the open-source route—which offered a low threshold of entry but a progressively expensive maintenance profile—make a better ROI than purchasing a completely integrated package from a reputable source? IT resources were limited. How was this open-source solution going to fit into the IT culture and workload that currently existed? What would management have to pay in the future?

The Jury Is Still Out

The decision about which direction to go is still to be made by the company I've just described. But the understanding the company has gained about open-source packages and the necessary decision-making processes has been an eye-opener for the company's management.

To be clear, management's requirements could be met by the open-source solution IT had investigated, but the costs and the effort had initially been substantially underestimated. And regardless of the initial bottom-line savings, management was left with a lot of questions about the wisdom of moving into the open-source arena with a critical application.

IT's View

IT had done its job, but it found the results less than satisfying. It had hoped that the levels of complication in integrating and implementing one of the best and most popular open-source CMS applications would be less arduous. IT had hoped it could accomplish management's goals without resorting to consultants. It had hoped that management's solution would also be IT's solution.

Nonetheless, IT was impressed with the structure and the sophistication of the base Joomla CMS. It was impressed with the commitment of the authors of the base package, and the hundreds of developers who had authored extensions. There was no way IT could not be impressed. Joomla is a gem! A gem in the rough, but a gem nonetheless!

Open Source: The Reality

In the final analysis, the open-source process in a business environment is not about free code or even exceptional code. It's not about licenses or authorship.

No! Instead, the process of implementing an open-source application in a business environment should be about business! It's about functionality and integration into the work environment, delivering a measurable ROI for the benefit of the organization.

This company's IT and management experience found the results to be both puzzling and troubling, leaving many questions answered.

Thomas M. Stockwell is Editor in Chief of MC Press, LP.

Thomas M. Stockwell is an independent IT analyst and writer. He is the former Editor in Chief of MC Press Online and Midrange Computing magazine and has over 20 years of experience as a programmer, systems engineer, IT director, industry analyst, author, speaker, consultant, and editor.  

 

Tom works from his home in the Napa Valley in California. He can be reached at ITincendiary.com.

 

 

Also Read

IBM i Shops Pivot to Battle COVID-19

Energy, Vibe, and Atmosphere

Murphy’s Security Law