Ever since IBM shipped the Integrated Development Environment (ILE), they suggested that third-party developers would prosper by creating "libraries" of extensions to the RPG language. To date, there have been a few success stories, but nothing remotely similar to what IBM predicted.

As I see it, the reason that there have been few major success stories in that market space is primarily because barriers to market are numerous to say the least. Certainly, if a package of tools, utilities, extensions, or packages (call them what you may) that enhanced RPG or improved programmer productivity were available, people would support it, right?

On other platforms, there is a huge commercial market for these kinds of tools. In fact, one software distributor, Programmers Paradise, makes millions of dollars annually on reselling what seem to be simple tools, utilities, and extensions (called "add-ons") for the non-OS/400 marketplace (i.e., Windows, Linux, and Mac). These add-ons and tools can cut down on weeks or months of programming time.

For example, assume you are creating an application for Windows and would like to include a spreadsheet within your application that can read and display Microsoft Excel documents. You can spend hours attempting to get Excel integrated into your application and then require your end-users to have Excel installed, or you could attempt to write a spreadsheet component yourself. Good luck with that!

Or you could simply spend a few hundred dollars on a spreadsheet component from one of the vendors that offers them and then install that component into your application. So rather than spend months building your own component or weeks integrating Excel, you have your application up and working in a few hours.

Because the components you license are also licensed by thousands of others, the market can afford to create and maintain components of much higher quality than could be created in-house. In addition, by licensing third-party components, you encourage the vendor(s) to create new components that you or others may need in the future. It all comes down to deciding if you are in the tool/component building business or applications software business.

This relates to the iSeries market in obvious ways. As I said at the outset, there are few iSeries software companies in this segment of the market. In the days of System/38, there were vendors working hard on these kinds of products, but most have gone their own way. Today, most software vendors have fully integrated packages that cost thousands of dollars. Not a bad deal for the platform. In fact, since many companies are replacing their legacy applications with contemporary applications, this is good news for application software vendors. But what about legacy applications?

I define legacy applications as applications that have already been installed and implemented. Age does not matter. Should in-house applications programmers have the kinds of tools they need to get things done more quickly, or should they be expected to reinvent the wheel every time a new configuration or component structure is required?

Suppose, for example, you require an extension to an application that allows an order to generate an XML document and a transaction from an order (for whatever reason). How many days will it take before your application developer will be able to get that kind of code up and running? How efficient will that code be, how flexible will the design be to allow it to be used by other programs, and what else could the developer have been working on instead of building the XML conversion tool? These are all important questions.

Now, suppose that a third party or two specializes in components or add-ons to RPG and OS/400 application development and sells an XML conversion add-on. Is it worth your time and effort to investigate the component and perhaps license it vs. building it in-house? Let's compare these two methods and see which one looks better on paper.

The "Make" Scenario

A typical application developer would probably take about three weeks (a very good one maybe eight days to two weeks) to build the code for an XML component. The component would probably be unique to the original application to which it was designed. This would require it to be enhanced/modified each time a similar function needed to be implemented in a new application.

So if a programmer earns about $1,200 per week (I'm using rough numbers based on Midwestern averages and rounding), at the two-week mark, the component would cost you at least $2,400 plus overhead and at the three-week mark it would cost you $3,600 plus overhead. This does not, of course, account for the lost time that could have been used to maintain or create your business applications. If you have great programmers who could create this XML component in eight days, you're probably paying them more than $1,200 per week, so the cost may be similar.

The "Buy" Scenario

Suppose an XML component could be licensed from a vendor for $2,995 along with the customary 15% annual software subscription (maintenance contract). Over a two-year period, the package would cost between $3,450 and $3,900, depending on how the maintenance licensing is structured.

What's the Difference?

To do a comparison, consider that typical employees cost an extra 15% beyond their salary (for overhead) and use the high-end licensing fees with software maintenance for at least two years. You end up with about a $240 difference. This means the cost is the roughly the same to make or buy something like an XML component.

So if pricing is the same, then you need to look at quality. Often vendors will include other useful (and not-so-useful) components, tools, utilities, etc. in their packages. For example, perhaps the vendor includes a method to convert a database file to an XML document and copy it from the native OS/400 database to an IFS file.

In the world of components and add-ons, a vendor may include anywhere from a handful to a dozen or more useful items in the same package, for the same licensing fee. And it is here where the economics begin to weigh in on the side of buy vs. make.

Taking into account all of the costs to your company--including the lost development time--and the extra features you'll find in most packages, purchasing a component package can be a real value. Finally, consider this. If your out-of-pocket costs are roughly equal in the make vs. buy scenario, then you have already paid for an additional year or two of software enhancements. So any new features, components, or tools added to the package you've licensed should be yours automatically--no additional out-of-pocket expenses. Suddenly the market for OS/400 components and add-ins makes sense. But will any more people enter the market? To answer that question, all you have to do is ask, "How do you want to spend your money?"