How Richard Stallman got me to ponder extremism

This evening, I had the opportunity to attend a speech by a man whose work over the past decades enters into my life on a daily basis. The Network for Computational Nanotechnology at Purdue hosted Richard Stallman, the founder of the GNU Project and the Free Software Foundation. Stallman is a well-known and controversial figure, not only because of his technical work, but also (primarily?) because of his idealism and activism. His un-nuanced views and public lack of tact have driven fans of his work away from the FSF. I went into the talk expecting some pot-stirring. I didn’t expect to walk out deep in thought.

Stallman opened with a discussion of terminology, drawing a distinction between free (for the purposes of this post, free software means libre, not gratis) and proprietary software.  It is an ethical, social, and political distinction, not a technical one. Free software, Stallman argues, is a contribution to society. Proprietary software is morally unjust. Stallman prefers, given the choice between writing proprietary software and doing nothing, that developers do nothing. Even though free software is often available at no cost, encouraging the adoption of free software should be framed as a moral issue, not an economic or practical one. Software as a Service (SaaS) is morally equal to proprietary software in Stallman’s view, regardless of the licensing of the software, because users have no control over it.

During the question-and-answer session at the end, this view brought a heated discussion from NCN director Dr. Gerhard Klimeck. NCN runs nanoHUB, which is effectively SaaS for nanotechnology simulation. Stallman seemed to argue that it was a niche and not really important to discuss. He also semi-adroitly dodged the question of how developers can make money with free software, only asserting that it is being done without providing the [mostly student] audience any insights as to how.

Stallman’s views are based on his personal morality and seem to be absolute. This is what occupied my thoughts on the walk back to my car. Because I largely agree with Stallman, I’ve been inclined to see his extremism as an annoying, but useful thing. By being on the edge, he defines the middle. But why should extremism that I happen to generally agree with be more valid than extremism that I disagree with? While extremism does help define the middle ground, it also poisons reasonable discussion. I admire and appreciate his technical accomplishments, but I think he hurts his own ideological cause.

Book Review: The Deadline

Project management is an underrepresented genre in fiction. That it even exists is probably no small surprise to many, and probably of interest to even fewer. There is very little about project management that the average reader would find sexy or thrilling. Fortunately, Tom DeMarco makes no attempts at either (despite the occasional hint of a romantic undercurrent).

I wasn’t sure what to expect when my professor mentioned this book in class recently — perhaps a dashing project manager who sweeps through saving the day and buckling swashes at every opportunity. Instead, the reader is given Webster Tompkins, a competent and entirely normal project manager with years of experience and a looming layoff (or, in the words of Mr. Tompkins’ barely fictitious employer: “Released to Seek Opportunities Elsewhere”). While dozing in the back of an assembly, Tompkins is whisked off to the former Soviet state of Morovia. The Noble National Leader plans to turn his small country into the world leader in shrink-wrapped software, and Tompkins is just the man to lead the way.

What sets The Deadline apart as a novel is its entirely unconcealed intention to be a learning tool. The plot, exaggerated conditions and all, serves as a framework to present critical project management wisdom. Conveniently, Tompkins keeps a journal in which is writes these lessons as they occur, condensing the knowledge into bite-sized nuggets. What sets The Deadline apart as a learning tool is its readability. Although this book could readily be used in a formal project management course, it is interesting and well-written. Unlike the dialogue in project management scenarios given in textbooks (which, with apologies to Brewer and Dittman, is lousy), The Deadline reads like actual conversations had been transcribed. The end result is an informative and entertaining read that goes by far too quickly.

Perhaps the most striking thing about DeMarco’s novel is the publication date: 1997. At no time during my reading did I find myself thinking “boy, I’m sure glad that problem is solved now.” Although the nature of IT has changed in the decade and a half since The Deadline was written, the lessons are still very applicable. Especially when it comes to managing the human resources, it seems the lessons are still being relearned by each successive generation of managers (or sometimes not). Being a systems engineer and not a developer may slant my view of the current state, and it is entirely likely that software development managers have absorbed these lessons better. Until then, this book should required reading for every IT manager, project manager or otherwise.