In my opinion your are putting on the table an important question, dear Barbara.
The question is how approaching the GLAM tools.
In every software there is a need, after there is a development, and after there is an acceptance because who asked to have a tool may say that the "functionalities" don't match the requirements.
The tool can be fantastic, multitasking, multifunctional, portable, efficient, and so on BUT cannot do some basic functions required by a GLAM project.
The main problem, for instance, is that it's hard to use, not friendly, it requires a long training...
The problem is to have technicians designing softwares for technicians or implementing softwares for technicians.
I think that it's fundamental that the requests and the acceptance MUST be done by GLAM operators and that the tools must implement ONLY what is required, nothing else.
I remember that some months ago there was a discussion here about the tools required by GLAM projects... there were several emails and the request was for the GLAMwiki tooolkit.
After some months it would be happy to know who is using it, which projects are having benefits from it and how quantify the relation costs/benefits.
I think that the GLAM-coordinators must take their right position in this process and must organize a "task force" to collect requirements and to submit these requirements to the community of developers and to evaluate the final results asking for corrections or re-engineering. If the GLAM coordinators will not be bold, the risk is to have terabytes of unusable software or tools.