Linux has been a success on many fronts. It has provided an affordable operating system alternative to Windows, it has popularized the concept of open source software, and it has been used by many as a platform to experiment with new ideas, spurring innovation. Yet, Linux distributions, especially commercial ones from which users have higher expectations of quality, have a lot of room for improvement. I would like to see distributions where everything provided binds together into a coherent whole: documentation, command-line interfaces, GUI tools, file formats.
One of the strengths of Unix has been the pervasive application of a few simple ideas and conventions throughout the system: all commands can process data read from their standard input and will print results on their standard output; all commands, interfaces, devices, and file formats are documented in separate sections of the online documentation; all configuration data is stored in textual files; code duplication is avoided through reusable libraries; all resources are available via the file system interface. Linux-based systems have contributed to these ideasthink of the rich data that is nowadays available through the /proc filesystem. Yet many of the distributed packages don't play by these rules. I would prefer to see distributions that focus on consistency over choice. By eliminating renegade packages from their distribution (do users really need twelve different file archivers?) and contributing patches that improve the consistency of the selected packages, distributions would exert evolutionary pressure toward the provision of higher quality building blocks.
LP: What can the Linux community learn from the travails of the Windows Vista release?
Although we don't know for sure what plagued Windows Vista (I think there's sufficient material available to write a book with insights comparable to Brooks's The Mythical Man Month), enough has been published by Microsoft insiders on blogs to give us a rough idea of the problems. I believe that Linux is not immune to them. More than twenty years ago Manny Lehman argued convincingly that the software's structure decays through the evolutionary changes we apply to it, unless we invest effort to spruce its structure up. The agile software community has aptly termed the shortfall between added features and missing refactoring as technical debt. In open source development the addition of features is more glamorous than the refactoring of code. Refactoring can create short-term stability problems and sour developer relations in return for long-term benefits that are not easily perceivable.
My research group is heading SQO-OSS: a multi-national EU research project to create a software quality observatory for open source software. I believe that making the quality of open source software a measurable and observable attribute will be a small first step toward higher quality systems.
One of the attributes I think the Linux community should focus on is complexity. It appears that this delayed Vista, and it has the potential to burry Linux in the long term. There are many techniques to harness complexity. We need to increase modularity, and limit undesirable coupling. As a first step we need tools that can measure these attributes (you've probably heard that you can't improve what you can't measure) and pinpoint problems areas; as a second step we should setup incentive mechanisms for contributing code that will address the problems we'll uncover.
LP: Any final thoughts?
The open source movement has been a catalyst for many aspects of software development. It has allowed us to learn from the code others have written, it gave us the opportunity to examine the quality of the code behind an application's façade, it has provided us with many high quality development tools and reusable components, and it has shifted the attention of our community from a focus on the process that was on the verge of becoming fruitless back to the rich intricacies of the product. I was lucky to be able to explore these possibilities in Code Reading and Code Quality.
Currently, system administrators throughout the world toil solving similar problems again and again. Yes software uniquely allows us to store what Phillip Armour has perceptively termed "executable knowledge." In the future I hope to see complex system administration tasks developed, packaged, and deployed using open source software collaboration methodologies.
Diomidis Spinellis is an Associate Professor in the Department of Management Science and Technology at the Athens University of Economics and Business, Greece. His research interests include software engineering tools, programming languages, and computer security. He holds an MEng in Software Engineering and a PhD in Computer Science both from Imperial College London. He has published more than 100 technical papers in the areas of software engineering, information security, and ubiquitous computing. He has also written the two Open Source Perspective books: Code Reading (Software Development Productivity Award 2004), and Code Quality. He is a member of the IEEE Software editorial board, authoring the regular "Tools of the Trade" column.
Dr. Spinellis is a FreeBSD committer and the author of a number of open-source software packages, libraries, and tools. He is a member of the ACM, the IEEE, and the Usenix Association; a four times winner of the International Obfuscated C Code Contest and a member of the crew listed in the Usenix Association 1993 Lifetime Achievement Award.
Diomidis Spinellis. Code Quality: The Open Source Perspective. Addison-Wesley, 2006.
Using hundreds of examples from open source software projects, like the Apache web and application servers, the X Window System, and the HSQLDB Java database, this book illustrates code quality concepts that every developer should appreciate and apply. From this book you will learn how to judge software code quality attributes: reliability, security, time and space performance, portability, accuracy, and maintainability. Having mastered this art, you'll then be able to apply your new-found sense to the code you write on your own and to the code written by others, aiming to assess its quality aspects and improve what you find lacking. You can also use your acquired knowledge of code quality when you discuss implementation alternatives with your colleagues, hopefully nudging your project toward the most appropriate direction.
This article was first published on LinuxPlanet.com.