Pages: pp. 8-9
I enjoyed Robert Glass's column "Viruses Are Beginning to Get to Me!" (Jan./Feb. 2005) on the incidence of spam and email-borne viruses. I've found an effective method for preventing both from reaching my PC: disposable email addresses. My email provider is Mailshell ( www.mailshell.com/mail/client/fd.html?fd=29), which offers a for-pay service that assigns subdomains to subscribers. A Web-based interface makes it easy to create and delete addresses, much like the virtual credit card numbers that some banks now offer. I create what I call assigned and temporary addresses. An example of the former is SomeOrg@mysubdomain.mailshell.com address. I keep this address live at all times and only give it to SomeOrg. An example of the latter is email@example.com. I created this one in early January and used it for such purposes as getting receipts from online businesses. A few weeks later, I deleted this address and began using a different one.
This system has two benefits. First, it doesn't matter if someone gives away one of my temporary addresses, since it'll soon be invalid anyway. The rate of temp address turnover has resulted in my receiving no spam. And second, if I get spam at an assigned address, I know who to take to task for it since I've given that address only to them. Surprisingly, this has happened only once in three years.
Those who don't manage their own domain might find Mailshell to be a viable, cost-effective alternative to buying antispam software and updating it every year. I hope this information has been useful, and I appreciate your service to our community.
Jim Carole, CSDP
I was browsing through the March/April issue of IEEE Software and was really disturbed when I saw Gregor Hohpe's article "Your Coffee Shop Doesn't Use Two-Phase Commit." My first thought was, "Who wrote this?" I knew this topic wasn't original, so I quickly did a Google search to find the author of the original, called "Starbucks Does Not Use Two-Phase Commit" ( www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html). At least the author of the two articles is the same. I actually really enjoyed this topic the first time I read it.
However, I look to the IEEE Computer Society for original material (a stated requirement in your publishing guidelines). I find it disturbing that Software would publish an article that's not original and is essentially self-plagiarized. See an interesting article on the topic of self-plagiarism in Communications of the ACM ( http://doi.acm.org/10.1145/179606.179731).
I encourage you to stick with original material in future issues.
Senior architect, Anexinet
Certainly, authors have a responsibility to inform editors when submitting material that has appeared elsewhere. In the current case, column editor Martin Fowler and the contributor discussed this very issue before deciding to use the material.
Once an editor learns of some form of prior publication, that editor and/or the editor in chief must decide if the material is publishable. For a peer-reviewed contribution, such as our technical articles, the procedure would involve the editor in chief and/or the associate editor in chief most closely related to the paper's topic.
Regardless of the manuscript's status as either a column or a peer-reviewed submission, the editors would evaluate it within the context of the IEEE's Publication Policy, which states:
IEEE's technical publications shall include original material which appears only once in the archival literature. Unusual circumstances may allow for exceptions to this policy. … It is common in technical publishing for material to be presented at various stages of its evolution. As one example, this can take the form of publishing early ideas in a workshop, more developed work in a conference and fully developed contributions as journal or transactions papers. The IEEE recognizes the importance of this evolutionary publication process as an important means of scientific communication and fully supports this publishing paradigm.
The two critical aspects of this policy are the venue where the material previously appeared and the work's evolutionary nature.
Regarding the first issue, the policy clearly indicates that we're concerned about republishing material from the archival literature. Archival sources usually imply that libraries should be able to store and catalog content so that others can recover it, even many years in the future, and that there should be a formal way of citing the document so others can make reliable references to it, whether in a week or a decade.
Regarding the second issue, the reference to "stages of evolution" suggests that we expect, as a manuscript moves from workshop paper to conference proceeding to journal article, that the ideas will be refined over time. In the past, the IEEE operationalized this expectation as a requirement of 30 percent new material. More recently, the IEEE acknowledged the subjectivity of this objective-sounding metric and changed the requirement to simply "substantial changes."
There are many good reasons for allowing—even encouraging—republication of nonarchival material, and very few reasons not to. By its nature, nonarchival material reasonably exists during a brief window in time and is usually available to a limited audience. Many good papers appear in the proceedings of small, semiformal workshops yet are only available to the 20 or 30 researchers who participated. The vast majority of papers presented at these workshops will never be distributed outside the immediate attendee list unless they are republished in an archival venue.
For instance, ICSE 2005 hosts 19 such workshops. Few, if any, of these papers will be indexed by a library or available to curious graduate students 10 years from now. If I'm not one of the fortunate few who can travel to St. Louis this spring, I will likely never hear of this work unless it's republished in another venue. I would vigorously argue that barring publication of this work simply because it appeared in a semiformal workshop would prevent many good ideas from being disseminated.
Your concerns about Gregor Hohpe's column raise some interesting points that we must evaluate within the context of the IEEE Publication Policy. It's true that you can find portions of Gregor's piece in a shorter article (1,040 words as compared to the 1,776 words in the IEEE Software piece—certainly an evolutionary change), entitled "Starbucks Does Not Use Two-Phase Commit," in a section of his Web site called "Gregor's Ramblings."
It's equally true that we can hardly consider an individual's Web site to be part of the archival literature. In fact, Gregor is quite clear on the status of the documents on his Web site: "I call them 'ramblings' because these notes are typically based on my personal opinions and observations as opposed to official 'articles.'" Short of providing a URL, there's no way to index, reference, or access the article. We all know about Web sites' relative volatility. Will that article still be stored in the public_html/ramblings directory five years from now? 10? 20? Will the domain even be active? Like the workshop proceedings, will this document be read by only a handful of people and lost to the rest of us? If Gregor isn't going to archive it for us, who is?
In fact, since you "really enjoyed the topic" when you read it on Gregor's Web site (as I did when I read it), it would seem logical to want an evolved version of this material to become part of the archival literature—which it certainly is now. This way, others will have access to this entertaining and informative "rambling" for many years into the future.
Editor in Chief