point
Menu
Magazines
Browse by year:
Your Open Source Strategy
Ted Schadler
Thursday, June 26, 2008
OPEN SOURCE SOFTWARE IS QUIETLY changing the dynamics of the software industry. Enterprises as diverse as FedEx, Morgan Stanley, Oracle, and Google are running enterprise workloads on open source software like Linux and Apache—often on low-cost, Intel-based servers. So what’s the ultimate impact of open source software on corporations, vendors, and service providers? Quite simply, to bring commodity values—low-cost, high-reliability, and wide choice—to infrastructure software.

Despite its recent rise to fame, open source software isn’t new—after all, it’s anchored the Internet with BIND and Sendmail for decades and runs more Web servers than any proprietary alternative. What’s different now? Open source software —and the hardware from Intel and AMD that most users run it on—has passed the good-enough point. Put another way, today’s open source rewards outweigh the risks (see Fig. 1).

But sorting through the open source propaganda and avoiding open source choices that don’t make sense—like desktop operating systems—isn’t easy. To avoid these gaffes, start your strategy planning process with answers to these questions:
• What’s different about open source software?
• Which open source products should firms use?
• What’s the right open source deployment strategy?
•What’s Different About Open Source Software?

Open source software differs from commercial software in important ways that stem from its development processes and licensing terms (see Fig. 2). CIOs should understand three key dimensions:

Development: The scientific method yields great platform software. The open source development process is analogous to the scientific method—with published results, peer review, etc. It’s particularly well-suited to commodity infrastructure software because the incentives for open source contribution—accolades of a large community and the personal satisfaction of seeing your code broadly adopted—are mostly found in platform software rather than niche application software.
Licensing: typically free. Open source software licenses are usually free. But beware: Other costs—like documentation, support, and commercial add-ons—will still swell firms’ IT budgets. In Linux, for example, Red Hat’s revenues are for subscriptions (code base maintenance) and service rather than licenses. One note: The general public license (GPL) terms—under which direct enhancements to Linux must be made open source—are sometimes seen as a fatal flaw in the open source story. Forrester disagrees. Open source licensing models allow it to be used in commercial software, though in different ways depending on the license terms.
Support: a broad array of choices. Open source software has four kinds of vendors competing for support: • distributors like SuSE for Linux or Covalent Technologies for Apache; • hardware vendors like Dell, HP, and IBM; • software vendors like SAP and Oracle; and • traditional systems integrators and outsourcers. These vendors compete fiercely on quality and price, yielding an efficient market for buyers.

Which Open Source Software Should Firms Use?
SourceForge.net reports more than 50,000 open source projects. But let’s be clear: Only a handful are ready for datacenter deployments. In general, firms should (see Fig. 3):

Accept open source in embedded systems. Linux is popping up in many storage subsystems and network appliances; every device needs an operating system, and Linux is free and reliable. Firms can comfortably accept Linux inside a DataPower XML switch or in a Panasonic DVD-RAM drive. Why? Because it’s the hardware vendor’s job to support the software—not yours.

Consider open source for commodity platform software. Open source’s sweet spot is in platform software: the Linux OS, Apache Web server, and PHP scripting language. The bottom line? If you’re a Unix shop today, you’ll probably be a Linux shop tomorrow. Why? Your skills, procedures, and even apps will port easily—and you’ll save on the Web server, OS, and hardware. Amazon’s well-publicized move from Solaris to Linux on HP Pentium-based servers helped cut Amazon’s technology capital budget by 25%.

Avoid open source on the desktop and for most apps and tools. With the success of Linux and Apache, it seems like every vendor and developer has initiated an open source product. But for the next three years, CIOs will be smart to avoid most of them because most will fail one of Forrester’s three enterprise open source filters: a five-year history, 20 book titles available on Amazon.com, and commercial support.

What’s The Right Open Source Deployment Strategy?
Firms can deploy and benefit from open source software without jumping into the open source community. In fact, companies that don’t have a deep technology “build” culture should treat open source like commercial software: Hands off the code. How should beginners deploy open source software?

Deploy Linux—don’t worry about SCO’s frivolous lawsuit. Forrester’s research with 877 large North American companies shows that already 17% of them have deployed Linux for core applications. And with commercial support from giants like HP, IBM, Oracle, and SAP, Linux’s future in the datacenter is assured. What about the SCO lawsuit against IBM? It’s about money—and IBM will ultimately make the problem go away. Enterprises carry no more risk with Linux than they do with any new technology.

Fund an open source competency center and staff it with skeptics. CIOs making a commitment to open source should also commit to a team that can demystify licensing issues, manage code rollouts, and sanity-check projects. Staffing the center with skeptics—not gurus—will keep corporate technology policy far away from the open source socialist fringe.

Treat open source deployments more rigorously than commercial ones. With open source, the cost barrier to upgrades is gone, right? Wrong—most of the cost of upgrades is in labor, not software licenses. Indeed, the hidden costs of upgrades, such as incompatibilities with other applications and hardware patches, may be even more severe in an open source environment. Smart IT execs will learn by engaging a partner like HP or Red Hat for Linux deployment support.

Don’t modify open source code unless you want to join the community. Only firms that want to see their utilities, tools, and extensions maintained by someone else should modify or extend the code—especially with code like Linux that’s protected by the GNU General Public License (GPL). See the Open Source Initiative (www.opensource.org) for more information about open source licenses.

Predictions About The Impact Of Open Source
What will be the five-year impact of open source development on the software industry? One thing’s for sure: Open source software will gobble up more application and middleware workloads.

Open source will slash software infrastructure pricing. JBoss and Apache Tomcat are already closing in on commercial J2EE app servers and servlet engines. In three years, low-cost open source middleware will cut the prices of commercial app servers from BEA, IBM, Oracle, and Sun—and Microsoft, too—by 30%.

Microsoft will successfully avoid being “open sourced.” Microsoft’s desktop domination or ramp into the enterprise is not in danger of disappearing. Why not? Because Microsoft will aggressively innovate and cut costs to keep Linux and open source out of the enterprise desktop—it’s future relies on it. And for server software, Microsoft’s tight integration and optimized stack will resist open source attacks. It is only on phones, games, and cable TV boxes that Microsoft will fail to resist the open source onslaught.

Larry Ellison will establish the “Ellison Prize” for software innovation. Today, open source software is better at creating stable versions of known technologies than introducing entirely new kinds of software. What’s missing is not the process—rather, it’s the motivation to innovate. In contrast, scientists can look to prizes like the Nobel as a motivator for innovation. So today’s software barons should create their own $1 million prize, starting with an award for Kernighan, Ritchie, and Thompson, the Bell Labs crew that gave us C and the Unix kernel.



Twitter
Share on LinkedIn
facebook