Red Hat 7.0 introduces a major change from previous versions in the form of systemd. systemd replaces a number of longtime core services such as system initialization and syslog. The pros and cons of systemd have been discussed at length and I won’t rehash them here. My interest in systemd is from the change management perspective.
Red Hat 7.0 represents a change that breaks compatibility with previous versions. It is revolutionary rather than evolutionary. In my view this is rarely, or perhaps even never, a good idea. This has nothing to do with the merits of the technology, it is about change management. Software operates in a complex ecosystem, therefore even small changes can have major impacts. This is why mission critical systems evolve so slowly. Change entails risk and the greater the change the greater the risk.
There is no doubt that the many of the existing Linux services such as syslog needed serious improvement. The question is how to change them. We know from biological evolution that major change is possible over time though a series of small changes. The only requirement is time and patience. Even the venerable syslog could be changed incrementally over time to provide modern features such as structured log messages. This would be the low risk approach.
One of the risks in a large, breaking change is that it will fail. This kind of change does not have a very good track record in software. Several programming languages have tried this and failed: Python 3, Perl 6, and Scheme r4s. Failure in this sense means low adoption. In Windows 8 Microsoft also made several major changes that have fared poorly such as removing the start menu and the metro UI. Apple is usually very good at evolutionary change but even they were tempted by the lure of revolution and made a huge misstep with Final Cut Pro X (aka the infamous “iMovie Pro”). Gnome 3 is also an example of this phenomenon.
Usually, the failure isn’t total it’s partial. More often what happens is fragmentation, the community (or user base) becomes divided. This is worse than total failure. Now you have two things to contend with, the old and the new. If, for example, you are Python developer do you target Python 2 or Python 3? Maybe both. The point is that now it has become more complex and more work for little if any benefit. This is what I am afraid will happen to Linux.
We may be entering the era of Linux1 (traditional init, syslog, etc.) and Linux2 (systemd). Even though Debian has also adopted systemd only time will tell if Linux2 will be a success. Businesses will probably take a wait-and-see position, especially if they already have a complex centralized logging architecture. Community adoption will determine if Linux2 becomes a success or if Linux shares Python’s fate.
The other thing I am concerned about is the affect these changes have on, for lack of a better term, community morale. It appeared to me (as distant observer only) that the r4s had a negative impact on the Scheme community. Maybe I’m wrong but it looked like that to me. My feeling is is that if a large percentage of your community is against something then it’s a bad idea.
My point is simply that major, incompatible changes are high risk. They have a poor record of success and they risk fragmenting the community. Furthermore they are unnecessary. Major changes can be done incrementally and with low risk.
Instead, introduce a radical change as a new product line, as Apple should have done with Final Cut Pro. Python 3 should have been new programming language (Rattlesnake?). The goal is not to hinder innovation but to manage it.