I read a pair of articles today courtesy of my daily ACM tech notes newsletter (join ACM now if you aren't already a member--it's an amazing resource on a bunch of different levels). Even though they were listed separately I saw them as related in an interesting way, and it got me thinking about a variety of things that have been formulating in my head for a while so the time seemed right to try and share some of these thoughts in a semi-coherent fashion.As is probably no surprise to people who know me or have had any interaction with me in the past year or so, I've been thinking a lot about the importance of free software (which is a preferable term over "open source") on a much bigger scale. I've always been a big fan of free software but for various reasons and through various influences, free software for me has become less of a fascination and more of a firmly held belief. Software is everywhere, it has (or can have) a profound impact on every aspect of society, and because of this power I believe we have to be increasingly cognizant of what software does, the reach it has, whether or not we're free to use it as we wish and, more importantly, whether or not we're free to verify what it's doing for practical or more purely academic reasons.First and foremost, free software isn't about getting something free of charge. That's not even a consideration in my mind. Free software is about transparency and openness, it's about freedom of choice, and it's about the freedom to share with and learn from one another. I have a much greater interest these days in learning things by studying code and subsequently using that code than I do in paying someone for a product that I may use only in a restricted way and have no ability to see what's going on inside the software
As Richard Stallman says in many of his talks, software started out in the best traditions of academia and programmers shared knowledge freely. Somewhere along the line for some factions of programmers, software became more about intellectual property and less about learning and sharing, and these two different philosophies are what we see playing both against and with one another in the software industry today. Given the degree to which free software is influencing and being integrated into traditionally proprietary segments of the industry it's clear that the free software movement is making inroads. In some cases the uneasy partnership between proprietary and free software is far more about marketing than it is about freedom, while in other cases there is true synergy between what some would call the Utopian aspects of the free software movement and more commercial interests.I hope that's a nice background into how I view free software and it may even shed some light on some of what I've been saying and doing over the past few months. The real reason for those few paragraphs, however, was to provide a backdrop for the discussion of the two articles I mentioned above, namely "Software's Dirty Little Secret," which is an interview with Grady Booch on the Scientific American web site (a CFML powered site no less!), and the even more scary sounding "Flaws in medical coding can kill: Spread of computers creates new dangers, FDA officials warn" from the Baltimore Sun's web site.I'll start with the scarier of the two first, which opens with the rather gripping line, "After a routine piece of medical equipment started mysteriously killing hospital patients a few years ago, the federal government turned to a small team of its software experts in suburban Maryland for help." Now I don't know about you, but even the coding I do may seem life and death at times, in the grand scheme of things it's rather inconsequential and, regardless of how it may feel in the heat of a tense project, it certainly won't literally mean life or death to anyone if I have a bug somewhere in my code.FDA recalls on medical devices were previously due solely to mechanical failures in the devices, but now there are an increasing number of recalls based on software problems. To quote Larry Kessler, director of the FDA's Office of Science and Engineering Laboratories, "Where it gets to be scary is, we used to have more human intervention. With software doing more now, we need to have a lower tolerance for mistakes." And perhaps more ominous is a quotation from Paul Anderson, president of engineering at a company that makes forensic software to detect errors in medical devices: "If architects worked this way, they'd only be able to find flaws by building a building and then watching it fall down."Not a ringing endorsement of how we do things in our discipline, and it goes right to the heart (literally) about the importance of software in modern society. People with embedded medical devices literally rely on software, written by human beings potentially under unrealistic deadlines and all the other pressures that are commonplace in software development, to live. I can't even begin to imagine how differently I'd think about the code I write if I knew it was going to be keeping someone alive, and even with that in mind, mistakes are still making their way into medical device software. Clearly a change in how we do things is in order, and you can probably guess what in my opinion a big part of the solution must be.This leads directly into the interview with Grady Booch, who is a fellow at IBM and a "self-proclaimed 'software archaeologist.'" Booch reaches many of the same conclusions as the FDA software experts: how we're doing things isn't working. In the first article the solution pointed mostly towards extensive and highly rigorous testing, which is of course is of vital importance in general and particularly in the medical field. Booch is focused more on the mainstream consumer device segment of the software world and looks at things a bit differently, but again uses more traditional engineering and architecture disciplines as a point of comparison.So what's the dirty little secret in software? There's little to no discipline in our discipline.To be fair, software development has evolved largely through trial and error since its inception, but the problem Booch sees is that the bulk of this trial-and-error knowledge exists in the brains of the people who have been through it as opposed to in publicly available resources. (Keep that "publicly available" bit in mind because we'll come back to it later.)If software has architecture, it's more by chance than by design, and this may have been tolerable for the first few decades of the software age. Now however, Booch states, "society ... runs on software," and much of that software is developed by hook or by crook over a period of years without much regard to its initial architecture let alone how it will be maintained as it ages. In many cases, Booch points out, companies are their software. Google and eBay, for example, don't have any tangible products to speak of, and since these companies in turn drive the economy, a lot is riding on the roughly 33 billion lines of code produced in the world each year.I encourage you to read both of these articles in their entirety to get a real sense of how important software is to society. If you haven't considered this before, now is the time, and once you start getting a sense of it I guarantee you'll start thinking about how you write your seemingly inconsequential code a whole lot differently. From the small applications we write that drive our companies, to the communications devices we rely on to connect to one another, to the voting machines that we entrust to accurately record our choices for our national and world leaders, to the medical devices some of us rely upon to live, software is a big deal, and programmers are entrusted with a huge responsibility that will only become more massive as every aspect of society becomes nearly completely reliant upon software to function.Now that I have everyone scared, motivated, or hopefully a bit of both, we'll turn back to free/open source software because I think it's an absolutely critical part of the discussion. Booch (from the "Software's Dirty Little Secret" interview) calls himself a "software archaeologist," and I thought his description of what this means was absolutely fascinating. With Booch, as with Stallman, it seems that software is about sharing and learning. For Stallman the sharing and learning leans perhaps a bit more towards the philosophical side, while for Booch there is a very practical aspect of sharing and learning: how else are we going to learn from our mistakes over time, and how else are we going to finally begin to create the architectural manuals of our discipline?One computer mecca that I hope to visit someday very soon is the Computer History Museum in Mountain View, CA. I'm a total geek when it comes to old computer hardware and the evolution of computers, and how far we've come so quickly fascinates me to no end. Booch has another idea that I find extremely compelling: in addition to the hardware history museum, we need a software history museum. Imagine what we could learn from studying the source code of things like early operating systems and early versions of programs that we still use today (how much of Word 1.0 code is still in Word 2008?), and how we could all benefit from having access to a historical timeline of how software has been developed over our relatively short history as a discipline.This of course presumes that all this code would be made publicly available. Much of it likely never will be, which is tremendously regrettable in my opinion. Companies with historical gems of proprietary software that no longer have commercial value should figure out a way to set this knowledge in the form of code free, and free/open source projects must each have stewards to record the history of the project and the lessons learned and carry these forward. We all spend far too much time writing code and far too little time sharing with and learning from one another, and if we don't share everything we can, our collective knowledge suffers greatly for it.Free software is the key to learning and sharing, but it's also the key to surviving as a society. We all rely on software a great deal every day and although that fact has probably been in the back of all of our minds for quite some time, it didn't really hit home for me personally until I read these two articles in succession. The back of our minds isn't where such an important notion belongs, and behind compilers isn't where something as important as software belongs. Eric S. Raymond is famous for the statement, "Given enough eyeballs, all bugs are shallow." As we move forward through time and depend on software for nearly everything, this statement becomes far more than a quaint Utopian ideal held by the fringe faction of the software world. It's an ideal that we all need to move firmly into the practical realm to improve our coding practices, our discipline, and our society as a whole.
Wow, I thought I am into Open Source software, but man, you are my hero :-)
Thank you for all the links. Good readings.
Matt, can you re-evaluate your style sheet? I'm having a time reading small gray font. Great stuff, please keep writing!
I'm also intrigued by 'abandonware'. I always thought it was cool id Software open-sourced older versions of their game engine. Seems like there is a lot of great software sitting on shelves no one will ever get to see.
Is Adobe really making money on the old Homesite code? Imagine if that had been open-sourced years ago...
@Richard--I'm planning on changing styles when I switch over to Open BlueDragon, which will probably happen this week. Just ramping up on Tomcat configuration. :-)
Great article, Matt, thanks for sharing! So if all software on the market were Free Software, do you believe is it possible that companies could still rely on direct consumer sales rather than the training/support model that many companies offering Free Software employ today?
If so, is there anything that would prevent someone from grabbing the entire code base and repackaging it as their own product? Are their license restrictions that address that sort of thing, or would this be allowed?
The idea of Free Software makes a whole lot of sense to me from philosophical and practical standpoints, I am just still wondering about some of the commercial aspects.
Matt, thank you so much for your blog piece and the links to the two articles which I will definitely read, of course this will deviate me slightly from the already unrealistic time frames I am under to produce a piece of software. My approach to software development be it as a developer or as a manager of some kind is that time is irrelevant but operability and excellence are not. Hence I have frustrated a good number of clients, I do not regret that at all. Their frustration has come either from my constant intonations of the need for operability or excellence or by the perception that I am slow at what I do. Thanks again for this post, it is in truth excellent.
that's funny @mike. when i do that, i just lay another brick on the "i'm the worst estimator in the world" pile.