Bridging the gap


If you're one of the growing number of Linux advocates working in corporate IT, chances are you're involved in a struggle. Your side, the Linux/open source side, is a grass roots movement. That means adoption is usually driven from the bottom up, not from the top down. Meanwhile IT management remains a top-down culture that prefers their "solutions" in the form of mandated strategy, not ad hoc problem-solving.

To understand what we're up against, it helps to visit the top-down side where it lives. That's what I did on June 27-30, 2004, in Boston, at the 32nd Annual Conference and Annual General Meeting of the Membership of the Information Systems Audit and Control Association: the ISACA.

For all of its 32 years, ISACA has been obsessed with governance, control, accountability, strategy, planning, risk reduction, business continuity and so on. Here's a sample of the educational sessions:

Not exactly box office with the open source crowd, one would assume.

Not surprisingly, open source wasn't on the agenda -- until this year, when I was invited to come and teach a class on "The Realities of Open Source".

Before and after I gave my talk, I sat in on a variety of other sessions. In every case I carried the only laptop in the room, other than the ones used by speakers to give PowerPoint presentations. When I pulled it out to take notes, or to work on my own talk, others looked at me like I was carrying a loaded weapon. Was I about to commit an act of wireless hacking, perhaps?

That would have been cool, of course, but not with this crowd. Open source, to them, smacks of the unknown. The very notion of "open" sounds like a security breach waiting to happen. A risk best "managed" by avoiding it in the first place.

So giving the talk was a fun challenge. I had addressed newbies before, but never newbies who also happened to work in IT Governance. I felt like I was explaining free enterprise to the Politbureau in the old USSR. Or communism to the Cato Institute. The cultural distance verged on the absolute.

I opened with the two questions I already knew were on everybody's mind:

  1. How do you design an audit to account for open source?
  2. For that Matter, how do you govern, control and assure it?

I answered by saying "We're not in Kansas any more" and proceeded to explain how many of the civilized graces we take for granted, from email and Web servers to Amazon and eBay, owed credit to open source developers, values and effects — all of which were as wild and uncontrollable as the next storm or earthquake.

That said, I went on to explain that open source was also about resourceful individuals and groups doing what needs to be done, that open source is an example of what happens when the demand side supplies itself, and that it can be understood as the DIY sector of the Information Systems construction and maintenance business.

I also said none of this was especially visible when you looking down at it from the parapets of Fort Business, demanding that it comply with approved procedures before Management dropped the bridge across the moat.

I showed the sizes of various open source conversations on the Web, which equaled or even exceeded those concerning Microsoft and other familiar names. I showed how much Linux and open source code was probably already running in attendees' companies, whether they knew it or not.

And I talked about common interests. For example, in the use value (rather than the sale value) of software. Also in low cost, availability, quality, integrity, efficiency, effectiveness, continuity, robust infrastructure, leveraged physical assets, problem solving and other virtues copied from the slides of other speakers.

In the Q&A we talked about SCO FUD and other predictable issues. One attendee demanded an explanation for why "they" (meaning open source advocates) had "such terrible manners". Later on a boat tour of Boston Harbor, she came up to me, waved a cigarette in my face, and insisted that open source people "have a good case, but they simply must change their behavior". But she couldn't give me an example of what she meant.

After my talk, several attendees told me they were, in fact, open source users and advocates inside their organizations (one was Monsanto), but that the prospects for open source in large conservative IT organizations was poor in the short term, even if they were good in the long term.

The main issue was "auditability". One attendee told me that open source stuff is, indeed, auditable (for example, the source code itself can be audited); but that this fact was still far from obvious.

It was clear, however, that for most attendees, open source just wasn't on their radar. "We don't have any, and we don't plan to have any," was the basic response. Another sign: the room was only half-full. The session after mine was on "Wireless Hacking Exposed". It was SRO.

In my July 9 SuitWatch newsletter, I wrote about the cultural divide I witnessed at the conference, and its near-absolute contrast from Supernova, the conference where I spoke just a couple days before ISACA. The theme for Supernova was decentralization. If anything, ISACA's theme was the polar opposite.

Immediately an email came from Glen Campbell, an IT consultant and veteran of both cultures. "The largest driving factor in most Fortune 2000 IT shops is risk mitigation," he said. "Likewise, the whole concept of DIY-IT is a complete anachronism to most IT shops. They did DIY-IT in the 60's, 70's, and 80's, and discovered that, no only is it less expensive to outsource their internal systems (to SAP, or Siebel, or EDS, or IBM), it also - tada! - reduces their risk in that there's another large corporation out there that they can sue if something goes wrong."

Customers requiring "six nines" of reliability have been getting it for years from the those same providers, or from HP, Sun or Novell. "That's why Sun can charge 10-50x for a server that runs Apache (which, by the way, is one of the very few open-soure packages that large companies have come to trust)", Campbell adds.

The regulatory environment has also elevated corporate IT paranoia.

Last year I attended a Harvard Business conference in New York where a procession of expensive consultants from Deloitte and other companies described the complex new reporting and accounting procedures required by the recently passed Sarbanes-Oxley act, which enforces, post-Enron, a much higher degree of corporate -- and personal -- accountability. Regardless of whatever good it intended to do, it was also clear that Sarbanes-Oxley promised to (borrowing Scott McNealy's immortal words) "darken the skies with consultants" and expand corporate bureaucracies.

IT Governance, for example. It was clear at ISACA that Sarbanes-Oxley was a godsend for members. Suddenly they found themselves standing exactly in the direction top corporate brass was forced by the new law to turn for help.

So, the question becomes, Where does open source fit in a Sarbanes-Oxley context? Here's Glen Campbell again:

I have a number of friends here in Silicon Valley who are on the "high-tech" side of the world. They simply cannot understand why, when you encounter an IT problem, a company doesn't gray Perl or Python and write a script that solves it. The IT guys, on the other hand, look at this with horror; how in the world could this hold up to a Sarbanes-Oxley investigation, which requires the CEO to personally sign off on the sources and validity of the corporate data? How in the world is the CEO going to understand a Perl script? The CEO will happily pay a 100 grand to avoid going to jail because of this.

And his isn't the only bad news. Another SuitWatch response included this:

...my organization's overlords, some of whom were probably at ISACA and most assuredly none of whom were at Supernova, have issued a blanket edict forbidding the use of Wi-Fi anywhere inside the entire (organization) and forbidding the use of Wi-Fi with any (organization) equipment anywhere at any time. Needless to say, the (organization) CIO is firmly anti-open-source and appears to be a vassal of Microsoft.

Yet Linux continues to grow in the enterprise. So does the whole LAMP suite. I'm writing this column in London, at the Identity Management Summit, where I just finished talking with Conn Crawford, who runs IT for the City of Sunderland, and with Nick Somper, Business Development Manager of Open Systems Management, Ltd. Both had Linux stories to tell. Crawford said his city just bought a Red Hat server to issue certificates for the city's PKI system. Somper's company does "adaptive systems management" for distributed and mixed environments that include UNIX, Linux and Windows systems. He not only sees Linux as a large and growing presence in IT, but perceived by many client companies as a fully legitimate OS.

Crawford and Somper both live in the market space where Linux has grown past the grass roots stage. It's part of the IT ecosystem in that space. Now the challenge is to make Linux more than safe -- in perception as well as reality -- for the large IT shops where risk aversion is a way of life. But before we do that, we need to understand the differences involved.

Adam Hertz, CTO of Ofoto, has a shop where DIY-IT and open source are ways of life. The company's whole business runs on systems developed almost entirely internally, on Linux and other open source components. It also grows at an extremely fast rate, adding up to two terabytes of storage every day. His whole business wouldn't be possible without open source, Linux and DIY-IT. From that perspective, here's what he sees in the relatively staid environments where most ISACA members live:

Two themes: BigCoIT is all about standardization and isolationism.

Standardization, so the story goes, reduces risks and costs. It certainly reduces complexity, but it can take a huge toll on flexibility and responsiveness.

Standardization often involves using one multi-purpose tool or platform to accomplish lots of different purposes. This often involves Customization, which is done by in-house experts our professional services firms. Examples: Siebel, Lotus Notes, etc.

DIY shops tend to be cynical, or even downright frightened, of systems like that, because they're so inflexible and unhackable.

Another form of standardization is what people are allowed to have on their desktop PCs. In a lot of big shops, everyone has the same disk image, with all applications preinstalled. There's a huge suspicion of anything that comes from the outside world, especially open source. It's regarded as flaky, virus-laden, unscalable, etc. This produces isolationism, which means major barriers to just trying something.

In more open environments, there's a permeable membrane between the corporate IT environment and the Net. People tend to get new tools from the net, usually open source, and just give 'em a spin. Culturally, this keeps the organization open to innovation and new approaches. It builds bonds between the employees and the development community on at large.

Standardized, isolationist shops miss out on all of this. The maintain control, but inevitably they fall behind.

If we want to sell Linux upward into risk-averse enterprises, it would help to follow the guidance, as well as the example, of J.P. Rangaswami, CIO of Dresdner Kleinwort Wasserstein, the $billion+ investment bank. When I asked J.P. to help make sense of the challenge here, he said,

Too many shops are currently executing uncertainty management rather than risk management. And because they don't understand the risk, they do the right thing and sit on their hands. Once you understand a risk you are able to price it and make a rational decision. So in my opinion shops differ in their ability to price risk, and the default position is risk aversion. Which may be far more expensive even in the short run than an active risk appetite. Witness the colossal sums spent on Y2000 just because people could not understand or price the risk.

DIY-IT is, when based on open source, defensible as a low risk position. More people inspect the code. There are more people using the code. There is more flexing of the code in differing circumstances. The issue is not of risk but of comprehension.

Last December Risk Waters named J.P. its CIO of the Year.


Doc Searls is Senior Editor of Linux Journal. Linux for Suits is his monthly column here. He also writes SuitWatch, a bi-weekly Linux Journal newsletter. And he presides over Doc Searls' IT Garage, a sister site to Linux Journal on the Web.