- DNMA92, ath9k and hostapd with Voyage Linux
- Slides for Open Source Developer talk at SFD
- Open Source Developer talk at Software Freedom Day 2009 HK
- Building compat-wireless drivers for 2.6.30
- leds-alix2 module in 2.6.30 kernel
- squashfs 4.0 on Debian Lenny and 2.6.30 kernel
- Upgrade Debian Etch Xen 3.0.2 to Lenny Xen 3.2
- Modrewriting viewcvs to viewvc in Apache2
- Upgrading Asus P1-AH2 with AMD Athlon 64 X2 5050e
- Debian Lenny Upgrade Experience
Software Evolution and Revolution
What is Evolution?
When a software or a system is released and goes into production level, the main codebase is in maintainence mode. That is, somehow, that code base will be under change control and only critical bug fixes will be allowed. All other features enhancements and less critical bug fixes will be put in next major release. From time to time after the some major release is completed, the software becomes a bit more different from the first release. This process is evolution. It means, a software evolves gradually through release cycle. But the process is slow and lengthy, especially when the software is sophsicated and complex, that makes the enhancement hard to implement unless a lot of changes.
Why Revolution?
In Evolution, software could be improved little by little through the process, or it may come worse and less stable. We could see Evolution is a way to improve the software, step by step. However, there are still some technical limitations in the software that evolution cannot be solved. These limitations are deeply rooted in the software. It is sometimes because that piece of software is rather new, the developers and the user have limited knownledge on how the software should behave. Or perhaps, the user only know what they need until they really use the system, especially when it is in production.
But somehow, some important features could not be implemented under the current code base. The implementation of these features touches and violates the current design. This makes the implementation so difficult, or if they are implemented, some of them may be less useful and some may fail user expectation.
In order to sort out all inheritance problems and to improve the software by a larger scale, a complete rewrite and rearchitecture of software is needed. This process is known as revolution.
Evolution and Revolution at the Same Time
However, when there is an existing software that undergoes evolution process, it is not possible for revolution to take place in the same code repository. Instead, a new chunk of code (repository) is needed in order to make it happen. This repository is referred to "revolution branch".
The revolution branch may contain some new pieces of code, some refactored versions of existing code from the evolution branch, and even new libraries and new executables. It is an rewrite and rearchitecture. It takes all the goods from the past experiences, removes all the bads. It is the code that we will need in the future, and also the code we should have had in the past.
Because of rewrite and rearchitecture, the revolution process also acts as a training ground for the new recruits. Since revolution touches very low-level layers of the software, it is the best place to train the new employs to learn and understand the fundamentals of technical implementation.
The revolution process may take at least 2-3 years before it gets into mature stage, at least, to make the software stable enough. However, the evolution process should retain a fast pace as it should be now, and should not be tampered by revolution. Of cource, the interaction between revolution and evolution processes is two way, so that any goods from revolution can be back-ported to the evolution path, and vice versa. Evolution and revolution benefits each other as a result.
Evolution and Revolution in the Real (Open Source) World
The developement of Apache Tomcat demonstrates a very good example of evolution and revolution. When Tomcat 3.2 was released, a very big controversial discussion was token place on what is next for Tomcat. The development community is divided into two groups, one for a optimized 3.3 which performs better than 3.2, while another group focus on 4.0 for the re-design of the servlet engine called Catalina.
In the development of Tomcat 5.0, the community is still using the same approach. 4.0 is in maintainence mode, 4.1 opts for a feature-riched and optimized version, while 5.0 incorporates more new features (Servlet 2.4 and JavaServer Pages 2.0) and its core Catalina and Jasper engine are partially rewritten to seek for higher scalablity and performance boost.
Mozilla is another revolution project. This is a open source version of Netscape 6/7. However, Mozilla project took for a high risk not to develop a evolved version but make their source open, and re-develop the whole browser from scratch, using a new code base. The outcome was letting Microsoft Internet Explorer eroding Netscape's market share. Even Netscape 7 was rolled out, the combined market share of Netscape and Mozilla is still less than 5%.
Even though Mozilla/Netscape losts shares to IE, it has successfully transformed into a Web Application development platform. It makes Mozilla not just a browser, but be able to plug-in any types application to that a Mozilla based. Moreover, NSPR, XPCOM, XPConnet, and XPToolkit/XUL (See Resources ) are some major cores foundation to make Mozilla so successful as application platform.
Revolt or Not Revolt?
From business perspective, evolution and revolution at the same time is not cost-effective. And this is correct. From the Tomcat case, the community was divided into two groups. If the resource were consolidated to focus on one version, the development of next Tomcat would be more effective. But since Tomcat is open source project formed by individual volunteers, the development cost is neglectable. The outcome is the community resources not fully utilized.
Some people may refer revolution as R&D approach. And R&D means it would fail. And the way that it fails is that the evolution process out-performes the revolution process. Mostly when it happens, the code developed in revolution branch should be able to contribute lots of codes to the evolution branch. In this stage, it should complete its job and retire. But then, another revolution is about to start over again. And this is not only just code contribution, but also the development team could gain invaluable experience from it.
Resources
- Apache Tomcat - from the Apache Jakarta Project
- Mozilla and its core technologies: NSPR , XPCOM , XPConnect and XPToolkit/XUL
- Mozilla - Other Projects and Browsers based on Mozilla's Gecko layout engine


