Communications of the ACM

Forum

Forum

Communications of the ACM, July 2005, Vol. 48 No. 7, Pages 11-13
10.1145/1070838.1070850
Comments

I commend David A. Patterson for his community leadership in highlighting a major issue in his President's Letter ("The State of Funding for New Initiatives in CS&E," Apr. 2005), moving it beyond the kind of discussions one might hear only at the Computing Research Association and the National Research Council. The changes at DARPA are notable not only for the lost opportunities they represent in computer science and engineering research but in what they mean to the broader DARPA mandate as well. With its emphasis on classified work and short-term deliverables, the current execution of DARPA programs seems to have also kept some research from the open examination of the best technical communities—a process critical to the advances that have long taken place under public-funding models. Long-term consequences involve the quality of technology deliverables for U.S. national defense, particularly from high-risk/high-reward research.

Technology research in the U.S. has been a model for the world in terms of its integration with education, along with co-investment by funding agencies and industry consortia. But U.S. technology dominance is threatened by the changing role of industry in long-term research. Despite more than $7 billion being spent by Microsoft, $5 billion by Intel, and some large amount by Google, the resources available for long-term research are drying up in an increasingly difficult environment for competitive research funding. This situation is bound to divert top talent—the kind needed to advance the Security, Privacy, Usability, and Reliability, or SPUR, agenda—from university jobs and careers in long-term research.

Though admittedly not a DARPA problem, these trends definitely involve public policy and long-term U.S. national competitiveness in the face of increasing government and consortia-led research elsewhere in the world.

I also want to note Patterson's advocacy for the profession through Communications. It may now be worthwhile to review the state of R&D spending in the semiconductor industry, which faces its own challenges due to dramatically shifting needs.

Rajesh Gupta
San Diego, CA

Back to Top

Don't Ignore the CIO's Legal Burdens

Hal Berghel's Digital Village ("The Two Sides of ROI: Return on Investment vs. Risk of Incarceration," Apr. 2005) analyzed the risks faced by CIOs as a result of recent legislation, particularly the Sarbanes-Oxley Act of 2002, or SOX. I fully agree with Berghel's conclusion that CIOs face increasing risks and that the legislation is changing the CIO's corporate role. I recently finished three in-depth exploratory case studies of organizations implementing SOX in the U.K.—two subsidiaries of U.S.-based organizations and a U.K.-based company listed on the New York Stock Exchange. The results have yielded several key insights:

Isolation. CIOs are isolated from the finance and business directors involved with SOX;

Lack of power. CIOs lack power or influence to change the processes and internal controls necessary for complying with SOX;

Not on board. The rest of the business has not embraced SOX in terms of its practices, processes, and controls. SOX is still in the preserve of the finance and compliance functions; and

Lack of skills. CIOs and the people in their departments lack the skills needed to deal with SOX.

Although these issues significantly increase the risk to CIOs, CIOs themselves have taken little or no action; meanwhile most of my academic colleagues in the U.K. wonder what SOX even has to do with IS. I am reminded of the cliché: There are those who make things happen, those who watch what's happening, and those who wonder what happened. No prize, however, for correctly guessing which group some contemporary CIOs and academics qualify for membership.

Ashley Braganza
Cranfield, England

Perhaps Hal Berghel misstated the scope of the rules involved in complying with the Health Insurance Portability and Accountability Act of 1996, or HIPAA (Apr. 2005), identifying them as applicable to the electronic personal health information (PHI) that companies maintain and transmit in the course of their normal operations. The HIPAA privacy rule applies to all PHI, whether or not it's electronic.

The HIPAA security rule—Berghel's main focus—is indeed limited to electronically maintained PHI. Only the HIPAA transaction standards rule specifically concerns data transmission and is largely limited to format and coding issues.

The interplay between the related privacy and security rules (enforced by different agencies) is not always clear. Illustrating a security rule violation, Berghel described a bystander who sees a health record on a workstation that's been left unattended. Positioning workstation monitors where a bystander can see them is a privacy rule violation. Not having a time-out after a reasonable period of inactivity is a security rule violation.

Health care and insurance providers, including employers (to the extent they administer group health plans), are defined as "covered entities" directly subject to HIPAA rules. HIPAA requires that they contractually monitor the companies with which they do business—their "business associates"—for compliance. For CIOs and CSOs, such requirements mean a new set of responsibilities.

Raymond L. Robert
Portland, OR

Author Responds:

I don't disagree with Robert's observations. Covering the Graham-Leach-Bliley Act of 1999, or GLB, along with SOX and HIPAA, in a column is by nature incomplete. I focused on only part of the IT domain and the risks to CIOs within it. For more, please go to my Web site: berghel.net/ col-edit/digital_village/apr-05/dv_4-05.php.

Version 2 of the SANS Institute's HIPAA Security Implementation was published shortly after the column went to press. I recommend it to anyone interested in the topic.

Hal Berghel
Las Vegas

Back to Top

Free Is Not Open Software

Michael A. Cusumano's Technology Strategy and Management column ("Reflections on Free and Open Source Software," Oct. 2004) suffered from a failure to distinguish the ethical principles of the free software movement from the practical and technical goals of the proponents of open source. He argued against claims made by the latter while suggesting they speak for all of us. They do not.

In the free software movement (www.gnu.org), which I founded in 1983, we seek and demand the freedom to control our own computers and cooperate with other users by redistributing software. Non-free (proprietary) software does not respect our freedom, so we reject it. To escape from non-free software and regain our freedom, we have developed free software (such as the GNU operating system). Cusumano equated "free software" with "gratis." We have nothing against paying for software copies and services or for programming work, as long as the freedoms are respected.

Open source (www.opensource.org), which began in 1998, largely adopted the practices and license criteria of free software but with a completely different philosophy citing only practical engineering values. Open source advocates a "development model," whereas we in the free software movement are more concerned with the freedoms respected by a program's license than with how its code is written. They do not argue that non-free software tramples the freedom of its users, as we do. Instead they say it is likely to be technically inferior.

Whether such a claim is true is an empirical question that might well be studied, but whatever the study's outcome, it has nothing to do with the ethical reasons software should be free.

Richard Stallman
Cambridge, MA

Author Responds:

Agreed, the "formal" free software movement and open source proponents differ, even though users and software companies may not find the distinctions important. I did overlook the argument that all software should be free. It is too extreme. Programmers have a right to earn a living, just as I do as a teacher, writer, and consultant. Nor would I demand that companies give away the computers and automobiles they make. But what a nice world it would be for some of us.

Michael Cusumano
Cambridge, MA

Back to Top

LEO Lives

Robert L. Glass's Practical Programmer column ("The First Business Application: A Significant Milestone in Software History," Mar. 2005) correctly pointed out the lack of attention given to events in the history of software, describing the "first business applications software"—the Lyons Electronic Office, or LEO, introduced in England in 1951. He concluded by saying "My regret is this: We in the software field should have made an event out of the 50th anniversary of this milestone. But that 50th anniversary should have happened in 2001."

Glass would be pleased to know that a celebration did indeed take place, as reported in the IEEE Annals of the History of Computing (Apr./June 2002), stating, "The jubilee celebration was held in the ancient Guildhall of The City of London under the auspices of the Worshipful Company of Information Technologists," with LEO pioneers, as well as more youthful computer scientists, in attendance.

Meanwhile, in 1999, the Association for Information Systems, an international society for academic researchers and faculty in the field of information systems and technology, established an award (similar to ACM's Turing Award) to "honor outstanding individuals who have contributed to the information systems community and recognize influential contributions to research, theory development, and practice in information systems." It's called the LEO Award.

Ephraim McLean
Atlanta, GA

Back to Top

Resolving the Dataless Dilemma in OO Programming

I compliment Chenglie Hu on his Technical Opinion ("Dataless Objects Considered Harmful," Feb. 2005), which cited my own Technical Opinion (" `Hello, World' Considered Harmful," Oct. 2001). I suspect this attention, as well as similar comments elsewhere, is due not just to my column's admitted problems but might also be the result of the widespread recognition of the difficulties involved in learning the seemingly intuitive OO paradigm—whether by students in their first programming classes or by programmers skilled in procedural languages.

Hu correctly identified the major flaw in my column—that the object created in my application class is "dataless" (stateless). I resolved it by creating a wrapper class that inherits from the static class I described. The wrapper class contains two types of data: a String that holds the name of the speaker and another String that holds the style of speaking. There is also a constructor that assigns the value "Anonymous" to the name and a randomly chosen style of speaking if no arguments are provided when creating the object.

To add interest to an initial introductory programming assignment, the static class was revised to include 10 different styles: abnormal, bouncy, doubleTalk, downer, encrypted, humble, programmer, shouting, stairs, and stretch. Although the style names are evocative, students must write code that uses them to find out what they really do. (Here's a sample of the "encrypted" style: "Gdkkn, vnqkc!") I posted the revised version on the SourceForge Web site and encourage you to download it from sourceforge.net/projects/hello-world-2/.

Ralph Westfall
Pomona, CA

Back to Top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2005 ACM, Inc.

---

No entries found