cost and risk of open source

             The Costs and Risks of Open Source=20

                     =20

=20

                                                                         =
                                         By Julie Giera =20

                                                                         =
                                        With Adam Brown

=20

=20

=20

=20

E X E C U T I V E S U M M A R Y=20

=20

Open source, including Linux, is being deployed by a majority of companie=
s in 2004, yet we question whether customers are adequately prepared to d=
eal with the costs and risks of managing these environments. The allure o=
f free software is accelerating the deployment of open source platforms, =
but open source is not free and may actually increase financial and busin=
ess risk. Discussions with five companies that tracked their total costs =
indicated Linux was between 5% and 20% more expensive than Windows. There=
 were two distinct situations where Linux was the clear cost winner: UNIX=
 migrations and Linux-only deployments. Linux, and other open source soft=
ware can provide big benefits to the organization, however, companies nee=
d to know what to expect, and plan appropriately to mitigate these concer=
ns.

=20

=20

=20

=20

OPEN SOURCE HITS THE MAINSTREAM=20

=20

Forrester conducted a survey of 140 North American companies on their use=
 of open source platforms in February 2004.1 we found the adoption of Lin=
ux and other open source components is accelerating in key areas of the e=
nterprise. This year, 60% of those companies surveyed indicate they have =
installed, or will install these platforms.

   1). the impact of open source is broader than just the platforms thems=
elves. The rapid Adoption of open source will place further pressure on c=
ommercial software providers that have endured slow license sales for the=
 past three years.2. The presence of open source in the enterprise delive=
rs not just the operational benefits of the platforms themselves but can =
also place the customer in a much stronger negotiating position with its =
commercial software providers.=20

                                                    Respondents indicate =
that the single biggest driver of open source deployment is cost reductio=
n. Eighty-six percent of firms say low acquisition cost is the major reas=
on for their open source decisions, followed closely by 77% that say they=
 expect to lower their total cost of ownership. But do open source platfo=
rms always save company money?

=20

=20

=20

Cost Reduction Is the Biggest Driver of Open Source Adoption=20

=20

=20

                      Forrester held in-depth discussions with 14 compani=
es that had been running Linux platforms longer than one year to see what=
 the costs really were. Several key themes emerged from these in-depth di=
scussions: =20

=20

=20

=20

Few companies know what they are really spending.=20

=20

Fewer than half of the companies we spoke to had a formal process in plac=
e to measure the financial impact of their open source choices. Only 5 of=
 14 had kept detailed metrics and of those five companies, Linux was more=
 expensive (5% to 20%) than the current Microsoft environments. Two of th=
e five companies said they expected their Linux costs to go down as they =
gained more experience.=20

=20

Preparation and planning takes longer with Linux.=20

=20

Virtually all of the companies we spoke with spent more time in preparati=
on and planning for their Linux deployments than with comparable Microsof=
t projects. Only one organization indicated that there were no appreciabl=
e differences between Linux and Windows in this area. This is not unexpec=
ted, since most of these firms are just beginning to establish operating =
procedures and practices for open source =97 for many, their Linux projec=
ts served as the catalyst for this effort. These preparation and planning=
 activities took 5% to 25% longer for Linux than Windows. This should cha=
nge, of course, as companies gain more experience with the platform.

=20

Training for Linux was more robust, more costly.=20

=20

We discovered that the investments companies made in training for their I=
T employees were significantly higher than for Linux than Windows =97 on =
average, 15% more expensive. When we asked why, almost all 14 organizatio=
ns cited two basic reasons: 1) training materials for Linux were less ava=
ilable than for Windows, limiting the choices companies had for courses a=
nd locations, and 2) customers adopted a more conservative approach to tr=
aining. Since Linux was new to IT, and would be a production platform, th=
e number of classes per employee was higher than for Windows. Companies f=
elt that because they already had several years=92 worth of experience on=
 Windows, they would need to schedule more training to overcompensate for=
 the lack of internal Linux knowledge.

=20

Software spending was lower, but not free.

=20

 Linux can be obtained through several vehicles. Customers can go through=
 distributors, such as Red Hat and Novell, to obtain the code, maintenanc=
e, fixes, patches, and support. Or they can take on the code themselves. =
It=92s interesting to note that the pricing models being offered from dis=
tributors for maintenance and support closely resemble the models used by=
 commercial software providers like Microsoft. The cost of software isn=92=
t just the cost of Linux or Windows =97 there still may need to be invest=
ments in systems management and monitoring tools, either direct investmen=
ts to purchase new products, or investments to upgrade/deploy Linux suppo=
rt in existing systems management suites.=20

Even so, for the 14 companies we interviewed software costs for Linux pro=
ved to be less expensive, on a per-server basis, than Windows by at least=
 60%.

=20

=20

=20

The cost of maintenance and support represents the bulk of spending.=20

=20

All five companies that had specifically tracked the total costs of their=
 Linux deployments said that maintenance and support were their biggest a=
reas of spend. The testing processes these companies used for Linux were =
more involved than for Windows. Companies told us they wanted to make sur=
e Linux would integrate well with their other platforms and that applicat=
ion suites would run in both environments. In all five companies, the fir=
ms chose to obtain maintenance and support from external vendors like Red=
 Hat and IBM, even though they had made significant investments in intern=
al IT training. Although we heard time and again that the frequency of Wi=
ndows patches =97 due to security concerns =97 was increasing the costs o=
f supporting that platform, companies still said Linux was costing them m=
ore in this category than Windows. The cost differences were mainly isola=
ted to companies that were running Linux in a mixed operating systems env=
ironment, and ranged from 3% to 14% higher th
 an
 Windows.=20

One CIO of a large US-based manufacturing company said, =93We planned pre=
tty well, we did a lot of training, but testing is taking longer than we =
expected.=94 Another VP of a medium-size healthcare organization said, =93=
The number of people I have assigned to Linux is almost double my Windows=
 staff for the same number of servers. Some of this is learning-curve rel=
ated, but honestly, this was a surprise.=94 She went on to say,=20

=93We think this will get better as we gain more experience, but I didn=92=
t expect it.=94 companies gain more experience with Linux and other open =
source platforms and the tools to manage these environments mature, we ex=
pect costs to decrease in this category. But vendors will also be moving =
more aggressively to package consulting and support services for these pl=
atforms, essentially commercializing open source as they=92ve done with p=
ackaged software suites.=20

=20

 Linux skills are expensive and hard to find.=20

=20

The 14 companies we spoke to said they had a hard time finding qualified =
Linux personnel in the marketplace to support their Linux projects. When =
these companies did find third-party help, they had less leverage negotia=
ting hourly rates than with other Windows consulting resources. Although =
these customers have been running Linux for more than a year, some of the=
 issues with availability and pricing have already begun to change. As th=
ese platforms become more pervasive, and more consulting firms develop th=
ese skills, the market will become more competitive, but for now that out=
side help is likely to cost an estimated 10% to 20% more per hour over si=
milarly skilled Windows help.=20

=20

Hardware savings are significant for UNIX customers moving to Linux.=20

=20

One of the customers had moved from an HP-Unix environment to a Linux pla=
tform. It ran Linux on smaller, cheaper servers, saving almost 45% in har=
dware and hardware maintenance to run the same workloads. And the savings=
 weren=92t just relegated to the cost of the box. The number of support t=
echnicians required for UNIX was estimated to be one technician for every=
 eight UNIX servers. The company estimated that one technician could now =
support 15 to 18 Linux platforms and that these ratios would just get bet=
ter over time.=20

=20

Linux-only deployments are also less expensive.=20

=20

The other situation where a customer saved significant amounts of money w=
ith Linux was in a new, =93Greenfield=94 deployment. This company was bui=
lding a new IT organization from scratch for a startup division of its or=
ganization. There was no legacy environment to migrate from and no requir=
ements for multiple operating systems to support. The CIO of this technol=
ogy company estimated his Linux deployment, =93Cost us around 20% less th=
an it would have cost us with Windows.=94 Most companies, though, don=92t=
 have the luxury of building a brand new IT organization.=20

=20

=20

=20

=20

Keeping Down the Costs of Open Source=20

=20

Customers with experience in open source deployments have said that good =
planning is the key to keeping costs low. It is important to understand t=
hat the cost of open source deployments will vary dramatically company by=
 company, however, there are common areas companies should address to avo=
id financial surprises.

=20

=20

Have an open source strategy.=20

=20

The decision whether or not to deploy open source technologies should be =
driven by the needs of the business, and be part of an overall IT strateg=
y. These decisions will broadly impact the organization, affecting everyt=
hing from the choice of business applications the company can use, to the=
 legal, regulatory, and financial risks of the organization. Decide how o=
pen source will be used, the way these platforms will be governed, how th=
is code will be supported, how it will be secured, and whether or not the=
 IT organization will be allowed to change the code. Keeping costs low in=
volves executing a formal plan, knowing where you are going, why, and plo=
tting a path to get there. Installing Linux next week because your CFO is=
 mad at Microsoft is probably not the best business decision.=20

=20

Establish the rules.=20

=20

=20

Companies that are trying to mitigate the cost of open source need to est=
ablish the rules around these platforms well in advance of deploying them=
. What licensing model(s) will be used? Will internal IT staff change the=
 code? Should the organization purchase maintenance from a distributor li=
ke Red Hat? Or, should the company buy maintenance and support from a com=
pany like IBM? What testing processes will be used for these components? =
How will security be dealt with? Can the IT staff download code from the =
community, like a hardware driver? Establishing the rules governing devel=
opment, maintenance, security, and support is not only important and nece=
ssary =97 it is one of the keys to saving money. Companies that are just =
venturing into open source now should obtain qualified outside assistance=
 with planning before installing any of this code.=20

=20

Licenses may be free, management of licensing is not.=20

=20

There are several different licensing models companies can use with open =
source.3 .The choice of licensing models will depend on several factors a=
nd the most important =97 will the customer change the code? Companies ne=
ed to pay particular attention to open source licensing, since a poor cho=
ice will not only cost significantly more money, it can also dramatically=
 increase the risk to the organization as a whole. For example, if a cust=
omer is planning to change the code, does the licensing model that was ch=
osen obligate the company to distribute those changes back to the open so=
urce community? If so, has money been set aside for that process? We reco=
mmend companies establish open source advisory groups to deal with the li=
censing and associated due diligence issues.=20

=20

Limit development

=20

Companies have understood for a long time that it costs much more money t=
o support a custom or customized environment than it does to support a pa=
ckaged software environment. Open source is no different. If an organizat=
ion wants to limit its financial exposure, the best alternative is to avo=
id changing the code. Remember, if you change it, you own it, and you sup=
port it. Just because a programmer can change the code, doesn=92t mean th=
ey should.

=20

Negotiate with commercial software providers.=20

=20

One of the interesting IT spending trends we=92ve seen in the past two ye=
ars has been lower spending for new commercial licenses and higher spendi=
ng for maintenance and support =97 that=92s because the costs of maintena=
nce and support have been rising steadily over the past three years. Comp=
anies with a defined open source strategy can negotiate with commercial s=
oftware providers to reduce these costs. Vendors, like Microsoft for exam=
ple, want to protect their install base, and will give some very attracti=
ve discounts and concessions, especially in the next few months before th=
e fiscal year end.

=20

=20

THE RISKS OF OPEN SOURCE ARE DIFFERENT THAN COMMERCIAL SOFTWARE

=20

=20

Open source technologies are not without risk. One of the primary reasons=
 commercial software companies exist is to shift the burden of maintenanc=
e, upgrades, and support away from internal IT. Commercial software compa=
nies take on the burden of operability, provide warranties on workmanship=
, defend against copyright infringements and intellectual property claims=
, and commit to supporting these platforms for specified periods of time.=
 The open source movement shifts all of those burdens to the customer.=20

There is so much hype right now surrounding the risks of open source that=
 it can be difficult for customers to know what is real and what is just =
politicking.

=20

=20

Risks Are Unique, but Commonalities Exist

=20

The risks of open source will depend somewhat on the individual customer =
environment, the industry the company is operating in, the knowledge and =
skill of internal personnel, the licensing model chosen, the organization=
al and governance models the company is employing, and whether the custom=
er intends to change the code. We recommend companies develop a risk asse=
ssment team to examine each of the risks of open source, rate those risks=
 in the context of their organization, and recommend strategies to mitiga=
te those risks before proceeding with the development of an open source s=
trategy. The follow areas of risk should be considered

=20

=20

        Warranty.=20

If the company makes changes to the code and provides that code to other =
organizations via either a product or service using that code, it may be =
assuming liabilities for the quality and workmanship of the platform. Inc=
idents of downtime or processing errors that affect business partners or =
customers could become a legal and financial liability.=20

=20

      Copyright infringement.

=20

Companies need to be especially careful around the topic of intellectual =
property. In the US, copyrights have been filed for not only lines of cod=
e, but also for topics such as look and feel, technical, or operational p=
rocesses. A programmer does not have to copy a line of code to infringe o=
n a copyright or intellectual property.

=20

Regulatory and compliance.=20

=20

Companies in regulated industries have to be concerned with regulatory co=
mpliance. For example, the FDIC alone can issue more than 30 regulatory c=
hanges a year to the banking community.=20

=20

=20

Operability

.=20

Companies that make open source components or products and services runni=
ng on open source components available to customers or business partners =
run the risk that the code won=92t work in the customer=92s environment. =
Support for older hardware, integration with older releases of other oper=
ating platforms, and problem resolution assistance may be implied in the =
existing contracts between the company and its partner. Companies that ar=
e making open source components or systems available outside the walls of=
 the organization need to make absolutely sure no contracts exist that pl=
ace them at risk. Companies should undertake, with the assistance of thei=
r legal department, a review of all contracts for products and services t=
hat may exist in the organization. This includes any existing agreements =
for business products, services, and support.=20

=20

 Licensing and usage rights.=20

=20

Companies can easily make a mistake surrounding the licensing of open sou=
rce code, especially when employees often just click through the usage ri=
ghts posted on free software Web sites. A GNU Public License, for example=
, could force the unwitting company to release to the open source communi=
ty =97 and therefore to competitors =97 any code changes made to these pl=
atforms. This could be disastrous. And, the problem isn=92t isolated to m=
istakes with the wrong license type. In some cases, a company=92s commerc=
ial software licenses may restrict usage rights in such a way as to limit=
, or prevent, interfacing open source components to the platforms.=20

=20

Security.=20

=20

Open source advocates say these platforms are more secure than commercial=
 software because they are open. But we think the biggest reason there ha=
ven=92t been more hacker attacks on open source is the relatively small f=
ootprint these components have within the enterprise. It is not at all un=
common for a company to have 50=20

Windows servers, three UNIX servers, and two Linux servers. Which platfor=
m do you think hackers will target? Companies should not be lulled into a=
 false sense of security with open source. It is open, available to anyon=
e that wants to do harm, and, therefore, needs to have special attention =
with testing and security.

=20

Dealing with Open Source Risks Requires Knowledge, Planning=20

=20

The risks to the organization with open source components are different t=
han other platforms; however, companies can move to lessen these risks wi=
th some common sense approaches.

=20

=20

The biggest concern companies have with open source is the lack of suppor=
t.=20

More than half of the 140 companies surveyed rated the lack of support as=
 a primary concern with open source. Even companies that have installed o=
pen source worry about support (see Figure 3). Fifty-seven percent of tho=
se firms said support was their primary concern. In fact, when we asked c=
ompanies why they did not have plans to use Linux open source, 53% said t=
hat a lack of support was one of the top reasons . Companies can mitigate=
 some of the support risks by employing the skills of third-party provide=
rs. Linux distributors like Red Hat and Novell are now offering maintenan=
ce and support offerings for this platform. Increasingly, services provid=
ers like IBM, HP, EDS, and CSC are offering support for many of these tec=
hnologies. Customers sign maintenance and support contracts much like tho=
se for commercial software, and receive product updates, fixes, and probl=
em resolution support in return. Companies that plan to support the code =
internally can purchase support incidents
 , or
 hours, from a knowledgeable provider =97 just in case they run into some=
thing they cannot resolve quickly.=20

=20

Review software licensing models.=20

=20

Companies need to be deliberate about their choice of licensing model, an=
d make sure the model aligns with their intentions. For example, a custom=
er that chooses a GPL licensing model may be bound to release all changes=
 (including proprietary intellectual property) to the open source communi=
ty, whether it intended to or not. Further, understanding the history of =
the code development is important because the company could discover that=
 someone, somewhere, infringed on copyrights earlier in the development o=
f the product =97 this is the basic issue with the current SCO lawsuits.4=
 Due diligence is a key part of licensing open source components.=20

=20

Don=92t change the code.=20

=20

The easiest way to mitigate risks is not to change the code. Of the 140 c=
ompanies we surveyed, 22% said they changed the code; perhaps that is not=
 a surprise. But 46% said they looked at the code and didn=92t change it.=
5 how do their companies know they didn=92t change the code? It is 4 p.m.=
, your Web site is down, it=92s the busiest time of the day, the programm=
er can see the code causing the problem and he doesn=92t change it to fix=
 the problem? Of the 14 direct customer interviews we did, only one compa=
ny said it had a formal audit process in place to ensure the code didn=92=
t get changed. We recommend every company installing open source componen=
ts involve their internal IT audit department, schedule regular periodic =
audits, and treat open source as they would any custom code in their envi=
ronment.

=20

If you do change code, isolate the development.=20

=20

Just because open source is open, doesn=92t mean companies shouldn=92t ap=
prove and control any changes to the code. In fact, we recommend companie=
s establish formal review and approval processes for any change proposed =
to an open source component due to the liability issues outlined above. W=
e further recommend companies isolate the development staff allowed to ma=
ke these changes and give permission only to the most experienced members=
 of the organization. This way, companies can ensure their most qualified=
 staff is responsible for adherence to company policies. These measures m=
ay be modified in the future as open source components become more widely=
 used and as experience grows.=20

 Form an open source advisory group.=20

=20

Only 11% of companies have established an open source advisory group, des=
pite the fact that more than 60% have, or will be installing these compon=
ents this year (see Figure 5).=20

We have received quite a few questions from clients about these advisory =
groups during the past several months, for example: Who should participat=
e in an open source advisory group? What should the charter of a team loo=
k like? We strongly recommend companies establish these teams with repres=
entation from legal, IT, internal audit, the IT steering committee, secur=
ity, and any vendor representatives that may be involved in creating or s=
upporting open source. The charter of this group should:=20

=20

=20

           =B7 Establish licensing standards and perform licensing due di=
ligence for the organization.=20

         =B7 Formulate internal development, testing, and change manageme=
nt processes for open source.

          =B7 Participate in the risk assessment group, rating and rankin=
g the risks of open source, and formulating strategies and processes to m=
itigate those risks.=20

          =B7 Watch the developments in the open source community to ensu=
re adequate development and support for the components the company is usi=
ng.

          =B7 Develop guidelines and approval processes for changes to op=
en source components.=20

         =B7 Create a support infrastructure, including identification of=
 external vendor support resources that could be available in a crisis.=20

          =B7 Work with HR to develop internal training, and external hir=
ing needs surrounding open source platforms and technologies.

=20

=20

=20

=20

R E C O M M E N D A T I O N S=20

COMPANIES CAN MITIGATE COSTS AND RISKS OF OPEN SOURCE=20

=20

=20

The costs and risks of open source are real, yet companies can do a lot t=
o minimize these problems:

=20

Plan appropriately.=20

=20

Open source can provide great benefits but companies have to cover the ba=
ses before deploying these platforms.=20

Establish risk assessment teams.=20

=20

Getting the business unit executives, audit, finance, and security to ass=
ess and plan for the company=92s unique risks is a crucial component of a=
 successful open source strategy.=20

=20

Minimize change

.=20

Companies that avoid changing code can save money and lessen the total ri=
sk to the organization.=20

=20

Get an advisory group.=20

=20

Although few companies have formalized this function within their organiz=
ations, it is crucial.=20

=20

Get help.=20

=20

Companies should employ the services of third-party providers, if only in=
 small, emergency support contracts to minimize the risks of downtime and=
 other production problems. Once a company has more experience with open =
source, it may be able to shoulder this maintenance and support burden; h=
owever, in the short term get experienced, outside help.=20

=20

=20

Track costs.

=20

Fewer than half of the companies we spoke with actually knew whether they=
 had saved any money with open source, yet the majority said it was the p=
rimary driver in their decision to move to the platform. Establish ongoin=
g measurements for support, maintenance, cost of management tools, cost o=
f governance and oversight, and costs of training.

=20

=20

=20

=20

=20

A L T E R N A T I V E V I E W=20

OPEN SOURCE WILL MATURE=20

=20

As open source adoption continues to grow, and as commercial services pro=
viders, such as EDS, HP, CSC, and Cap Gemini Ernst & Young, improve their=
 open source offerings, customers will have more choices available to the=
m for support, which will be less expensive than it is today, and the too=
ls available in the market to manage these platforms will become more rob=
ust and mature. It is possible, if the service provider community acceler=
ates their support of Linux and other open source components, that the co=
st of these resources will fall this year.

=20

=20

=20

SUPPLEMENTAL MATERIAL=20

=20

Methodology=20

=20

Forrester fielded an online survey to 140 US and Canadian companies that =
belong to the Forrester Executive Research Panel. We motivated respondent=
s by offering them a summary of the survey results and a chance to win a =
$50 Amazon.com gift certificate.=20

We heard from a mix of companies: 50% with revenues more than $1 billion,=
 20% with revenues between $500 million and $1 billion; and 30% with reve=
nues less than $500 million. Additionally, we did in-depth interviews wit=
h 14 companies that had been running=20

=20

Linux for longer than one year to determine the impact to IT costs.=20

=20

ENDNOTES=20

1 Forrester surveyed 140 large companies in North America to find out the=
ir open source plans.=20

While 39% will avoid open source for now, the 60% majority are adopting o=
pen source =97 and half of them use it for mission-critical applications.=
 Linux and Apache lead the list, but MySQL and Tomcat are close behind =97=
 and even the desktop is in play. See the March 16, 2004, Trends =93Open =
Source Moves into The Mainstream.=94=20

2 Our current forecast for US IT spending for 2004 is for growth of 4% fr=
om 2003, with 6% growth in 2005. Growth will be led by spending on comput=
er hardware, which will be up 9% in 2004 and 13% in 2005. See the Decembe=
r 29, 2003, Planning Assumption =93US IT Spending Forecast for 2004 =97 U=
p 4 Percent, as Spending Outpaces IT Budgets.=94=20

3 Enterprises are intrigued by open source software =97 but stymied by my=
ths of cost, support, and risk. Smart firms will master these myths to ge=
t the open software stack they want. See the September 23, 2003, Report =93=
You=92re Open Source Strategy.=94=20

4 SCO Group has filed a series of legal actions claiming copyright infrin=
gement by IBM in the creation of the Linux kernel by using SCO Unix code.=
 SCO has also sent notification to numerous companies using Linux, seekin=
g damages for this alleged infringement of its copyrights. The legal acti=
ons are pending in the US court systems. See the May 23, 2003, Report =93=
Mitigating the Risk:=20

SCO Group (Caldera) Puts 1,500 Companies Using Linux on Notice=94 and see=
 the December 5, 2003, =93Perspectives: What if SCO Wins =97 Linux Contin=
gency Planning.=94=20

5 Forrester surveyed 140 large companies in North America to find out the=
ir open source plans. While 39% will avoid open source for now, the 60% m=
ajority are adopting open source =97 and half of them use it for mission-=
critical applications. Linux and Apache lead the list, but MySQL and Tomc=
ats are close behind =97 and even the desktop is in play. See the March 1=
6, 2004, Trends =93Open Source Moves Into The Mainstream.=94


	=09
---------------------------------
Do you Yahoo!?
 Yahoo! Search presents - Jib Jab's 'Second Term'

----------------------------------------
|  Free Software Users Group - CUSAT   |
|  http://fsug-cusat.port5.com/        |
----------------------------------------