For example, OpenSSL is a very strong force behind what we call "internet", without something like OpenSSL we wouldn't have internet today. When heartbleed was found in OpenSSL the dynamic wasn't to retire OpenSSL and migrate to GnuTLS or something else, or even something new, but to patch OpenSSL. Why, because even though OpenSSL development is silent, we know that it IS maintained. If we find another heartbleed today, nobody will want to replace the entire cryptographic infrastructure of the internet, instead fix OpenSSL.
Another examples: zlib, SWI-Prolog, most BLAS implementations, some GCC backends, Concord (heuristic-based TSP solver), most parts of algo based libraries (CGAL, Eigen, GMP, GSL etc...) (of course these libraries are implementing new features, but there are some parts of codebase that didn't receive any commit for years)...
I think good signals to tell a package is complete: (1) there are no known critical bugs (2) if we found a critical bug today, we're reasonably sure we will get a fix in reasonable amount of time (3) project and project goals are well-documented (4) everything documented as goal is implemented i.e. there is no on-going development happening.
Another examples: zlib, SWI-Prolog, most BLAS implementations, some GCC backends, Concord (heuristic-based TSP solver), most parts of algo based libraries (CGAL, Eigen, GMP, GSL etc...) (of course these libraries are implementing new features, but there are some parts of codebase that didn't receive any commit for years)...
I think good signals to tell a package is complete: (1) there are no known critical bugs (2) if we found a critical bug today, we're reasonably sure we will get a fix in reasonable amount of time (3) project and project goals are well-documented (4) everything documented as goal is implemented i.e. there is no on-going development happening.