The original specification was extremely expensive to create, from the POV of a Lisp vendor. Today, there are few vendors left. In the early 00's, a bunch of

The original specification was extremely expensive to create, from the POV of a Lisp vendor. Today, there are few vendors left. In the early 00's, a bunch of users got together to create the next version of the specification, and only Franz and Lispworks were there (because they were the only ones left standing). It was a complete shitshow. The users were very enthusiastic about piling work on the two remaining vendors, and the vendors walked away from the table. I was there as a vendor, and it was frustrating. At the time, the users wanted to standardize multiprocessing APIs, yet no vendor had an SMP version of their API! For the decade after this aborted attempt, at least one vendor had to make lots of changes to their API. It would have been horrible to standardize the APIs of the time. None of the users wanted to hear this. This leads me to two main points: * Users not are the right crowd to standardize a language, because they do not have to implement the things they dream up. This is an important point. * Standardizing a multiple-source language when most of the sources are OSS, and the non-OSS sources are vendors do not derive much revenue from the language, is doomed to fail. It's economics. The best thing for Common Lisp: users make and support packages that work across many CLs, and users get the package via quicklisp.