Is bigger better?

May 1999/By Tony Baer
------------------------------------------------------------------------
 
With computer associates'' recent acqui-sition of Platinum Technology, it is tempting to conclude that independent software vendors are an endangered species. Not that there wasn't a fair share of irony or posturing that lead up to the deal. Platinum, which styled itself as the politically correct CA, was finally swallowed by its less-kind-and-gentle rival. And the noise about being a "better CA" was just "good theatre," said Platinum's Flip Filipowski at the press conference.

The wave of consolidations hitting the software industry is further proof that, as unique as information technology is to the economy, it is not immune to the same macroeconomic trends that are spawning the reassembly of John D. Rockefeller's Standard Oil Co. And even if the feds actually succeed in breaking up Microsoft, each Baby Bill is still likely to enjoy critical mass in its portion of the market.

If you examine the business plan of the typical software start-up today, merger or acquisition is usually the end game. The life cycle usually goes as follows:

Year 1 You hope to become something. Attract venture funding to support product development.

Year 2 You hope to become the next Microsoft. Secure round two of funding to finance the release of Versions 1.0 and 2.0 to the market.

Year 3 You realize that you're not going to become the next Microsoft. File for an Initial Public Offering (IPO) or find a buyer -- whichever comes first.

If you're an Internet firm, you hope to become the next Yahoo. You pray that you won't be the next Netscape. Accelerate this schedule by a factor of two or three.

With software such a growth industry, it's understandable that investors want to maximize their stakes. However, behind the macroeconomic trends is a very powerful market motivator for consolidation. Namely, customers' fears that they will be left with unsupported, orphaned software by a supplier that can no longer afford continued product development. It's the flip side of the expression that nobody every got fired for buying Microsoft.

And even Linux won't be immune from the mega-consolidation trend. Admittedly, the open source nature of Linux transforms kernel development to a public activity, where developers are invited to add changes.

However, can you imagine an enterprise running its huge Oracle database or enterprise resource planning (ERP) system on a locally unique dialect of Linux? Recent
investments by the likes of IBM, SAP and others into Linux distributors such as Red Hat indicate that, while customers may like open source code, when it comes to support, there's comfort in running the same thing that everybody else is. The last thing you want to hear at 3 a.m., when the server is overloaded by too many active threads during a month-end closing of the books, is that your particular Linux version is not supported.

While vendor size can deliver investment security, the obvious downside is losing freedom of choice, not to mention product innovation. But is freedom of choice worth the perceived risks? While choosing unique technology for enterprise systems may be career-limiting, for development tools that's not always the case.

Admittedly, back in the dark days of client/server, most tools were based on proprietary languages. The failure of a tools vendor often caused development organizations to throw out old applications and learn new tools from scratch. (How many SQL/Windows applications remain alive and well?) The dominance of PowerBuilder and Visual Basic therefore wasn't so surprising.

Fast forward

Fast forward to the emergence of Java, and the picture shifts radically. Substituting one Java IDE for another won't necessarily leave development organizations out in the cold, because the basic Java code should still be decipherable with another IDE. The only exception might be if the code is wrapped in a non-standard Java component architecture.

Therefore, developers should be free to choose the development environment that suits their approach to coding. That's a powerful motivator, because developers are a highly individualistic bunch, whose coding styles are often as unique as fingerprints. Just ask the guy who tracked down the developer of the Melissa Virus.

The bottom line is that standards like Java may be the best protection for independent software vendors. However, the operable question then becomes whether or not the technology can be easily replaced.