I know nothing about crypto, but I found comparing both codebases at a high level very instructive from a pure software engineering / project management standpoint:
In terms of sheer architecture, those two are almost epitomes of a very well maintained project (NSS) and a very poorly maintained one (OpenSSL). The OpenSSL codebase looks like it evolved for years with seldom any cleanups being done, with many people doing contributions, each person in its own unique style without much unification going on. The directory structure is chaotic, documentation is sparse, commented out code is laying around without any documented purpose, and browsing code at random you find things like this:
/* This should be using (bs-1) and bs instead of 7 and 8, but
* what the hell. */
if (bs == 8)
l=(l+7)/8*8;
It's pretty much what I would expect to happen if you simply gave everyone interested commit access, reviewed and refactored nothing, and only protested if something gets broken functionally. It's like an orchestra playing without a conductor, just a collection of "stuff" loosely connected together and corrected only as immediate needs surface. It might contain incredible individual pearls of crypto-wisdom of course, and tons of work has been put into it, but the technical debt is huge and paying it now all at once would be hard. I looked at GNU Emacs code a while ago, and had pretty similar overall impression, they for example have a test directory where every individual test suite (file) is done in a completely different style, being by a different author.
If you look at NSS on the other hand, you can tell there is someone who actually cares about the health of the codebase on a day to day basis. The directory structure is much more thought out, there are clear separate modules, there are way more tests, you can generate test coverage statistics, most function signatures are documented, there doesn't seem to be much redundant stuff in it, and so forth.
ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_16_RTM/src/nss-3.16-with-nspr-4.10.4.tar.gz
https://github.com/openssl/openssl
https://www.openssl.org/source/openssl-1.0.1g.tar.gz
In terms of sheer architecture, those two are almost epitomes of a very well maintained project (NSS) and a very poorly maintained one (OpenSSL). The OpenSSL codebase looks like it evolved for years with seldom any cleanups being done, with many people doing contributions, each person in its own unique style without much unification going on. The directory structure is chaotic, documentation is sparse, commented out code is laying around without any documented purpose, and browsing code at random you find things like this:
It's pretty much what I would expect to happen if you simply gave everyone interested commit access, reviewed and refactored nothing, and only protested if something gets broken functionally. It's like an orchestra playing without a conductor, just a collection of "stuff" loosely connected together and corrected only as immediate needs surface. It might contain incredible individual pearls of crypto-wisdom of course, and tons of work has been put into it, but the technical debt is huge and paying it now all at once would be hard. I looked at GNU Emacs code a while ago, and had pretty similar overall impression, they for example have a test directory where every individual test suite (file) is done in a completely different style, being by a different author.If you look at NSS on the other hand, you can tell there is someone who actually cares about the health of the codebase on a day to day basis. The directory structure is much more thought out, there are clear separate modules, there are way more tests, you can generate test coverage statistics, most function signatures are documented, there doesn't seem to be much redundant stuff in it, and so forth.