Thanks Thibault,

This express exactly my impression about ROS2 and DDS. On the other hand, I tried several time to contribute to ROS (core) and I actually haven't observed that it is possible to do so. So I guess that this is consistent.

I might be biased by the fact that the plugin-based architecture I proposed (and implemented) for the transport layer of ROS 1.0 could have implemented a DDS transport to test the suitability of DDS without changing a single line of code in everybody's packages. At the time, I was told that UDP multicasting, shared memory or bzip2 transport were not really useful because they would make roscpp too incompatible with rospy.

So for now, I'm waiting curiously to see what will happen but I'm reluctant to invest much time in the discussion.

On Thu, Oct 1, 2015 at 3:51 PM, Thibault Kruse via ros-users <ros-users@lists.ros.org> wrote:

On Tue, Sep 29, 2015 at 7:23 PM, Bill Smart via ros-users
<ros-users@lists.ros.org> wrote:
> Also, I was thinking about the (perceived) autocratic behaviour of OSRF, and
> about the origins of ROS. [...] Then Willow Garage came along,
> asked a bunch of people in the community what they thought, and implemented
> ROS. [...] Sometimes we have to stop talking and just do it, even if
> it's not the optimal strategy.

Hi Bill,

A difference between then and now is that Willow Garage did
not previously had any community that it could divide/hurt by creating ROS.

Also Willow Garage, despite having tight business goals (10K robots
in US households by 2015 IIRC), and despite having enough resources to
sustain it's own software, made the effort to nurture an open-source
community.
OSRF, without the pressure of business goals, and desperately needing
open-source contributions, instead ignores the open-source process (REPs), and
plans to make a release that will divide the community into sub-communities.

Willow Garage had strong and immediate pressure to provide a core that
the perception / manipulation / navigation / supervision teams inside Willow
Garage could easily use.
OSRF, not having a robot plattform to produce or support, does not have
this immediate feedback. OSRF could substitute the lack thereof by making small
increments to ROS1 that the large ROS1 community can validate in a lot of
real-world projects, but OSRF decided to rather validate ROS2 features with
some hello-world packages.

The behavior of OSRF does not only influence how quickly ROS2 will be
ready (if ever) or what technical features it provides. The behavior of OSRF
also influences how motivated anyone will feel to contribute to ROS.
And what value has ROS without it's contributors?

Nobody needs ROS2 to use DDS. There are open-source DDS libraries to use.
Not much is gained by delivering a ROS2 that's just a paper-thin layer on
top of DDS, but lacks the community momentum of ROS. That's why the
behavior of OSRF and the strategy for ROS2 matter. Ideally ROS2 should
not divide the community, and ROS2 should not make potential contributors
feel like their opinion does not matter.

regards,
Thibault

_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users

Cedric Pradalier