The Shape of Code

At some time in the future (or perhaps it has already happened) all the features needed (by users) in a widely used application will have been implemented in that application. Once this point is reached, do the software developers involved go off and do something else (leaving a few behind to fix lingering faults)? This is not good news for software developers, perhaps they should continue adding features and hope that users don’t notice.

When the application is a commercial product there is every incentive for new releases to be driven by income from upgrades rather than user needs. When users stop paying for upgrades it is time to shift to renting the application in the cloud rather than selling licenses.

With an Open Source application most of the development may be funded commercially or may be funded by the enjoyment that the primary developers obtain from what they do. For renting to be a viable option, a major service components needs to be included, e.g., Github offers hosting along with the use of Git.

Halting development on commercial products is easy, it happens automatically when paying customers drop below the cost of development. Work on Open Source is not so easily halted. The enjoyment from writing software is does not rely on external funding, it is internally generated (having other people use your software is always a buzz and is a kind of external funding).

If the original core developers of an Open Source project move onto something else and nobody takes over, the code stops changing. However, this might only be the death of one branch, not the end of the road for development of what the application does. Eventually another developer decides it would be fun to reimplement the application in their favorite language. An example of this in Asciidoc (a document formatter), where the core developer decided to terminate personal involvement at the end of 2013 (a few people are making local updates to their own copies of the source, at least according to the Github fork timeline). Another developer appeared on the scene and decided to reimplement the functionality in Ruby, Asciidoctor.

Reimplementation of a tool in another language is a surprisingly common activity. There is a breed of developers who thinks that programs written in the language currently occupying their thoughts are magically better than the same program written in another language. At the moment Rust is an easy entanglement for those needing a language to love.

Over time, it will become harder and harder to install and run Asciidoc, because the ecosystem of libraries it depends on have evolved away from the behavior that is relied on. AsciiDoctor will become the default choice because it works on the available platforms. Eventually the core developer of AsciiDoctor will terminate his personal involvement; and then? Perhaps somebody will step forward to maintain the Ruby version or perhaps somebody will decide to reimplement in another language and around we go again.

The evolutionary cycle of software in the future is starting to look like it well be:

1. developer(s) with enthusiasm and time on their hands, reimplement an application, (which is itself version n-1 of that application), in the language they love
2. time passes and users accumulate, while the developer(s) actively supports application_n,
3. those involved terminate involvement in supporting application_n,
4. more time passes, during which the software ecosystem that applications+n depends on changes,
5. successfully installing and running application_n is now so difficult that most users have migrated to application_(n+1).

Of course users will complain, but they don’t count in the world of Open Source (the role of users in Open Source is to provide adulation from which the core developers can extract sustenance).