Actually, there was plenty of free software available in 1992.
At about that time I was writing X.500 based applications using ISODE.
In my estimation, X.500 failed to take off for five reasons. The first was that it was overly complex. The protocol was certainly complex. While ISODE made things easier, building applications was still too complicated.
The second is that X.500 was a resource pig, both on the client and the server.
The third is that there were too many optional features in the protocol. No vendor could practically support all of the options and no two vendors could agree on a reasonably common subset of features. Interoperability was a nightmare.
The fourth is that due to its complex data model and binary data encoding, debugging X.500 sessions was extremely difficult using a packet sniffer or other protocol capturing tool. It also meant that writing scripts to do reasonably interesting X.500 things was not going to happen.
The fifth was that once LDAP was fielded, the practical need for X.500 disappeared. The first 3 reasons above created LDAP and once it existed, X.500 was an answer in search of a question.
One might say that there was no mission critical need to directory services. We had DNS for host to address mapping. Directory services was a "would be nice to have" not a "must have".
In addition, because it was originally conceived to be operated by the PTTs of the world, there was an organizational element with regard to who ran what servers and served what branches of the X.500 name space. That never really came together.
Many thought that company employee directories would be on-line for the world to browse. Except nobody checked with the companies to see if they thought that that was a good idea. It wasn't.
Reasons 1 through 4 above apply to many if not most if not all ISO (or OSI) protocols. We used to say that ISO protocols were designed to solve all problems for all people for all time. It turns out that because the protocols were too complex and too resource hungry, and the implementations didn't interoperate, that in the end they solved few problems, for few people, for a very short time. And that was on a particularly good day.
Designing protocols to solve every problem and provide every feature that we will ever need lost out to designing protocols that were the simplest things that would serve the desired purpose and solve the current problem. And these simple protocols (FTP, HTTP, NNTP, SMTP, POP3, TFTP, ...) have been augmented as new requirements have been encountered and are still relatively simple (to understand, to implement, to debug, to use, ...) today.
LDAP, however, is not one of these simple protocols. LDAP was a compromise, like SNMP, and like SNMP, LDAP has paid for not being what it could have been: small, simple, and elegant. Both protocols use the ISO data model (ASN.1) and the ISO encoding model (BER,DER,...). In fact, both protocols were designed to be transitional protocols to get things going until their ISO replacements (X.500 and CMOT (CMIP over TCP)) were ready to be deployed.
The funny thing is that once LDAP and SNMP were fielded, X.500 and CMOT were no longer needed. And funnier yet, the authors of the LDAP and SNMP protocols secretly knew that LDAP and SNMP would not be replaced by X.500 and CMOT, but they had to make the design compromise to ease the transition that they knew would never occur in order to keep the peace while they pulled the rug from beneath the X.500 and CMOT proponents. Of course this was back in the day when most people believed that X.400 would be replacing SMTP in no time at all. But some knew better.
