ISO's argument seems to be that the fees fund the actual standardisation process β trips to conferences, meetings and other "technical work".
I could agree for something like the international definition of physical quantities, where people have to do actual experiments, or travel to see equipment or even transport standard items.
But in software designs, often when you tip more resources into a project, you get a worse result. This is true for the C++ standard. Some necessary improvements occur (modules, finally, albeit incomplete with respect to build details), but as long as a large group of people meet to evaluate each others' proposals in a series of desirable resorts, the language will continue to grow in size and complexity whether or not it actually needs to. For example, adding "xvalues" to "lvalues" and "rvalues" may solve some earlier design problem in the standard library, but makes the language less understandable for users and implementers and the standards text more opaque.
Indeed, the standards language for C++ is so inscrutable one suspects that you need to be a full-time expert to fully understand it. It then becomes a career for the people involved in the standardisation. Now they have an incentive for the language to grow without bound, and the more complex and hard to understand it becomes, the better.
As far as I know the fees don't even pay for most of that stuff. Committee members have to pay to be part of a committee, usually paid by their employer. The time actually spent developing the standard is on the members' employers' payroll as well.
I could agree for something like the international definition of physical quantities, where people have to do actual experiments, or travel to see equipment or even transport standard items.
But in software designs, often when you tip more resources into a project, you get a worse result. This is true for the C++ standard. Some necessary improvements occur (modules, finally, albeit incomplete with respect to build details), but as long as a large group of people meet to evaluate each others' proposals in a series of desirable resorts, the language will continue to grow in size and complexity whether or not it actually needs to. For example, adding "xvalues" to "lvalues" and "rvalues" may solve some earlier design problem in the standard library, but makes the language less understandable for users and implementers and the standards text more opaque.
Indeed, the standards language for C++ is so inscrutable one suspects that you need to be a full-time expert to fully understand it. It then becomes a career for the people involved in the standardisation. Now they have an incentive for the language to grow without bound, and the more complex and hard to understand it becomes, the better.