I’ll be moderating a panel on day one of ROSCon, the topic of which will be “The ROS 2 Developer Experience.” We’ll try to cover as much ground as we can, touching on both technical and more community-focused aspects of ROS 2 development.
Part of the discussion will involve questions from the audience. Rather than seeking questions only from those in attendance, however, the panelists (Brian Wilcox, @Stephanie_Eng, and @ralph-lange) and I thought we should engage the wider community ahead of time and see if there’s anything you’d like for us to discuss.
I think the easiest thing to do here would be to post questions/discussion points in this thread, and then use the “like” system as a means of voting.
How do we prevent ROS development from being a closed ecosystem? How do we move from trying to create the “one all, be all” tooling for all programming languages, to using the industry standard for each?
Most other projects that have multi-language support say: “here is our C++ package, build it with cmake/bazel/make,” or “here is our python package: install it with pip” But instead ROS 2 (and ROS 1) says, “here is our hybrid C++ and python package, and now for all of the examples we are going to use a custom build tool (colcon or catkin) to build CMake with custom extensions (catkin or ament). Please install dependencies with our custom meta-package manager (rosdep). Oh, also you should probably be on our preferred version of OS.”
That creates barriers to entry, particularly for industrial users and experienced engineers.
ROS isn’t special. We shouldn’t use special tools.
You already can treat ROS packages as regular C++ packages or regular Python packages, but all of the tooling effort and documentation effort in the community goes into how to use them with the ROS tooling, not with standard tooling.
EDIT: obviously this is an opinionated post. But it is something I would like to see discussion about. My opinion is my justification for why I think we should talk about it as a community.