How good code dies

Or, how good documentation and stabilization can lead to a software project’s downfall.

New code libraries crop up all the time and present themselves as better than the more established ones. For example the library Controllerim argues that it does a much better job than Redux in handling application state (Source: The Ugly side of Redux).

Never mind that Controllerim has four contributors (at the time of writing) and Redux has 500+ contributors, thorough documentation and many supportive add-on libraries. Also, by building with Redux developers have solidified the code by filing and fixing issues on the project and accumulated real-world experiences.

I mean no ill will against Controllerim, it’s just a good example for the argument I’m trying to make. Which is, one might argue that open source projects evolve like so:

1. Initial commit of code.
2. It solves a problem with a bit of documentation.
3. Hype intensifies and developers flock to the code.
4. Project slowly matures, people learn, documentation is expanded.
5. The wealth of documentation starts repelling programmers with little time to read the manual. They would rather write some new code to solve their concrete problems than to spend time learning a mature library.
6. A programmer is sufficiently content about the solution to his/her concrete problem and decides to extract the code into a shiny new alternative to the mature library.
7. New library gains sudden hype.
8. Mature library starts receiving fewer commits due to stabilization.
9. Mature library is declared dead on popular developer site. Long live the new library.
10. This process re-starts from point 4 with the new library playing the part as the mature library.

I do love the hustle and bustle of the open source bazaar, but we should not be so quick to pass on tried and true code. If I’m building something that should stand the test of time I try to use libraries that look like they might be around in the not-so-distant future.