Change is painful, but it is necessary for a community to survive. Without change, the community dies.—Matz
We want our tools to be stable and predictable. If the design of a tool is finished and the implementation is correct, there is no need for it to change. As long as the problem remains the same, if we do not find a better solution there is no good reason to modify the code. Yet if the code does not change, the community around it may die.
Software can change in different ways and for different reasons. If backward compatibility is required, the available options are accretion and refinement. If compatibility can be broken, then features can be removed and the tool can mutate to either solve a different problem or solve the same problem with a different approach. The opening quote states that change is painful, and I have a double interpretation of that concept: it means that constant change requires constant adaptation, which causes pain; but it also means that by avoiding breaking changes and focusing only on accretion and refinement, the authors are trapped in the straitjacket of backward compatibility.
In order to understand how limiting it is for authors to enforce backward compatibility, it is necessary to recognize two important aspects of software craftsmanship: while the most obvious product of software development is the program created, it is arguably more important how the process as a learning experience affects the programmer.
By writing software we develop our skills, we become better at programming. When we have to enforce backward compatibility, our freedom to express new ideas is limited. In other words, when we are trapped in the straitjacket of backward compatibility, we may not be able to apply everything we have learnt.
One way to escape from the straitjacket of backward compatibility is to create an alternative tool instead of modifying the existing one. Niklaus Wirth created the programming languages Euler, Algol W, Pascal, Modula, Modula-2, Oberon, Oberon-2, and Oberon-07. He could have just iterated over the first one. Another example is what happened with Unix and Plan9. When the changes are radical, the result is usually a better tool with a smaller community.
The Linux Kernel is an example of a tool that preserves backward compatibility almost at all costs. The programming language Elm, on the other hand, has not been afraid of radical changes even if that meant the users had to adapt to new paradigms. Because Elm was able to change radically and profit from new ways of solving problems, its community grew smarter.
When software becomes stable, part of the community fades away because buzz tends to be proportional to the rate of change. Constant change yields better survival chances even if equally useful, more stable alternatives are available. Oftentimes the best course of action for stable software to grow its community is to simulate progress.
⊙