I agree with that, however: these contributions are highly focussed on technical functionality. Which is only natural, as the goal of the contributors is mainly to get their job done.
I think it is important to discriminate between ‘technical quality’ and ‘usability quality’.
The ‘technical quality’ is in fact already very high.
I have been astonished again and again by the available functionality in ROS 2 and Gazebo while developing my own application:
I run a ROS 2 setup for a multi-robot system with distributed control, online motion profile generation for synchronized motion, and operational modes configurable through parameters and launch files.
I have been able to fully debug my software, and I am currently implementing a perception system, without having the actual hardware available yet.
And the graphics are truly great as well, as I generated baked textures and light maps for all my models.
But: 1) I haven’t been running it 24/7 yet (so I can’t comment on stability for industrial use, holding my breath for that!), and 2) I has cost me blood, sweat and tears to get there.
Still now I often experience that adding a new feature requires extensive digging through code to look how something works or why it does not work as expected. And this indeed often still is very frustrating, even though in the meantime I got proficient at it, and learned best practices by doing.
This is the area of documentation / best practices / use cases / etc., i.e. ‘usability quality’. There’s a long way to go wrt this.
I don’t really see how the current organic way of waiting for community contributions can lead to significant progress in this area, at least not anytime soon. It is not in anyone’s get-my-job-done path.
I don’t think either that progress in this area is a task for the core contributing team. A core developer and a technical writer are typically different profiles.
I do think that this is a cause of a lot of frustration in the community, and I do think it hinders more wide-spread adoption of ROS 2 and Gazebo.