dcsimg

Time to Code without Compromise

If there's one thing that's certain, it's that today's shaky economy presents some new challenges to those of us in the technology sector. We are entering the "Age of Advantage." This means Linux, like all software serving the e-business economy, must demonstrate and deliver economic benefits: efficiency in resource utilization, speedy time to market, quick time to value, reducing complexity, increasing interoperability, and simplifying management of heterogeneous environments in an extended enterprise. These are the standards to which ISV (Independent Software Vendors) and in-house software developers will be held.

In the Trenches

If there’s one thing that’s certain, it’s that today’s shaky economy presents some new challenges to those of us in the technology sector. We are entering the “Age of Advantage.” This means Linux, like all software serving the e-business economy, must demonstrate and deliver economic benefits: efficiency in resource utilization, speedy time to market, quick time to value, reducing complexity, increasing interoperability, and simplifying management of heterogeneous environments in an extended enterprise. These are the standards to which ISV (Independent Software Vendors) and in-house software developers will be held.

Encouragingly, Linux has significant advantages in these areas, particularly in servers and embedded systems — but not as the be-all and end-all software tsunami that will wash away all that preceded it. Linux is a process, not an event, and as such, it is devoid of “tipping points” and “silver bullets.”

The challenge faced by the development community is to continually advance and enhance Linux’s natural advantages and turn them into business advantages.

A Call for “Code Without Compromise”

If business utility is what the future of Linux is all about, then applications are the key. The developer community has done yeoman work in creating and stabilizing Linux, developing advanced features and functionality, and getting it to run on many hardware platforms. But the time has come to begin the much more arduous and critical task that will take Linux to the next level: developing real applications that are native to Linux and building upon Linux’s natural ability to solve problems.

Clearly, for this to happen, Linux will need to continue maturing in terms of its ability to provide high availability, clustering, high security, and transactional throughput. But something even more important must happen as well.

In order for Linux applications to mature, Linux is going to need a true application development environment. Until recently, Linux was primarily treated by the marketplace as a hobbyist pursuit — campus coder geeks, laboring under flickering fluorescence in university sub-basements. Wrong. Serious developers at serious companies are intent upon doing real business with Linux, and they deserve — indeed, demand — serious tools for Rapid Application Development (RAD).

RAD, I contend, is the key to creating Linux applications with meaningful economic impact. The last part of that statement — meaningful economic impact — is especially important. For native Linux applications to be economically desirable to developers and the businesses that will deploy them, Linux development tools and components must evolve to allow fast, reliable, and economically compelling development efforts. The reality is that enterprise infrastructures will continue to be heterogeneous, with multiple platforms, operating systems, network topologies and applications that must be supported, integrated, and exploited to their fullest. Developers and e-businesses may desire diversity to achieve best of breed status and to optimize existing investments, but they cannot afford and will not tolerate balkanization of their infrastructures. The real world is complicated.

There is not one perfect language that will solve all IT problems. There is no über-OS — not Linux or anything else. Rather, each OS has its strengths and weaknesses, and, as I suggested in the beginning, the programmer’s task is to unlock and apply these advantages when and where they provide business utility.

However, it is important that we not make too many trade-offs in the pursuit of this goal. While interpretive programming is fast and easy, it’s not the best solution to all problems. Its strength lies in its ability to glue other tools together. Beyond that, the difficulty of “getting down to the metal” in an interpretive environment puts limits on its potential for application development. The other extreme is development using low-level compilers and a text editor. This can yield powerful results but also requires time-consuming development cycles and, in the end, doesn’t deliver the “economically meaningful impact” needed by both developers and business.

That’s why a common set of RAD tools is required to deliver “economically meaningful impact” and why one’s programming environment is so vital. RAD tools can give programmers the development speed of interpretive programming, the power of compiled languages, and the rapid development times afforded by a visual development environment combined with reusable components.

Developers need to be able to write to multiple operating systems and do not want to constantly reinvent the wheel or compromise their code. They shouldn’t have to make unnatural or unwarranted choices, sacrificing quality on the altar of expediency — or politics, for that matter.

Yes, if we’re honest with ourselves, we must come to grips with the reality that the absence of RAD tools may have as much to do with squabbling within the software industry and the open source community as it does with technological challenges.

A perfect example of this is Java and Linux. Enterprises now support both Java and Linux, and developers must have a common RAD tool for developing in both. This is the only way developers can quickly create quality applications that run on Linux and on Java. Let the marketplace decide what works, but don’t force programmers to write code with one hand tied behind their backs and without the benefit of a common toolset.

I would make a similar argument about Linux and XML. Ostensibly, they are complementary, but in the political world of technology, XML is an underpinning of Microsoft’s .NET initiative and, well, rumor has it that Microsoft and the Linux community have opinions of each other that go beyond the technology itself. If Linux, XML, and Java become embroiled in a barroom brawl, then not only does the entire software industry get a black eye, but so do the software developers who are trying to create great applications for e-businesses.

The issue is very real because we’re on the cusp of a new generation of e-business infrastructure built around Web Services that will use standard components to integrate and automate applications. J2EE and XML, along with SOAP, UDDI, and other emerging standards, are all critical to Web Services — as is Linux.

Web Services hold tremendous potential for leveraging Linux’s business and installed base advantages, particularly on the server and in embedded systems applications. But if Web Services development is crippled because programmers don’t have a common RAD toolset that allows them to develop natively on Linux, or on some other platform that they feel best suits their applications for this next generation of middleware, then the only thing Web Services will do is succeed in introducing another layer of complexity and confusion in an already convoluted e-business environment. And Linux will be poorer for it.

Keep Your Eye on the Prize

So, whenever I’m asked, “What’s next for Linux,” my answer is really very simple. Start concentrating resources where Linux has real business advantages. To deliver these benefits to the enterprise, our energies must shift to developing real and meaningful Linux applications, not simply cloning apps that were written for other operating systems.

But true Linux applications require true Linux RAD tools. This means more than tools for Linux. It means creating a common RAD toolset that enables developers to create applications simultaneously for Linux and for other leading and emerging operating systems and standards, with a particular emphasis on Web Services and XML. Both of them are critical to the next generation of e-business infrastructure and Web services.

In a sense, it means getting back to basics and keeping our eyes on the prize: giving software developers (who happen to be the real engine of e-business) the fuel that they need to accelerate Linux deployment in the heart of the enterprise — whenever, wherever, and however Linux can help drive business value.



Dale Fuller is President and CEO of Borland Software Corp.He can be reached at dfuller@borland.com.

Comments are closed.