> Unfortunately, we were affected by cognitive bias: old code is bad code. But the truth can be the opposite. The old code is battle-tested by thousands of users in hundreds of different projects. Most of the critical bugs have been fixed, the documentation is complete, there are tons of questions and answers on StackOverflow and Quora.
I'm quite guilty here; I've realized that I always check the date of the last commit on Github before testing a project. I feel like I do this more for small projects where documentation and use cases might be missing, and for which I'm expecting help from the community.
1. Project left in unfinished state and development stalled, in which case it's reasonable to run away from it.
2. Project done (fulfilling it's purpose) and turned to maintenance mode, in which case I'd be quite happy (as a matter of fact I'd prefer) to use it as I know I'm dealing with a stable codebase and don't need to be afraid of breaking changes in the future.
I think it would help if maintainers would state the "completeness" in the README file.
- 0.x = version in some beta/alpha/unstable state
- 1.x = version in somewhat stable/complete state
Word of mouth and some good old experimentation seem to be your best options for identifying solid tooling.
I realize it's tedious, but even older projects could do with periodic updates to tutorials, documentation, webpage updates and outreach to draw new interest from the community.
I do it because of code rot. The environment you will surround the project with (runtimes, libraries, frameworks) has often changed enough in 2-4 years to render it unusuable.
Additionally a recent commit implies regular maintenance which implies that if you report it will get fixed.
Also, projects are often abandoned because there is a clearly better version out there.
Check the mailing lists and forums; and look around for projects that depend on it.
Making GitHub stars ultimately meaningless, if they ever meaned anything.
This new project is quite nice and definitely a step up from mine.
Also wanted to mention that there is a CLI version of the visualizer at https://github.com/sheerun/graphqlviz for when you want to quickly visualize a GraphQL endpoint for documentation purposes, etc. Keep up the good work!
Are the "decades old" and "plain C" aspects supposed to be bad things? It seems like the real problem is "compiled to unreadable JavaScript". Graphviz is a great example of "if it ain't broke, don't fix it".
