Hi all,
I second many of Michael’s concerns, especially the part of his mail quoted below.
Frankly, the strategy review document reads almost like a horror story to me. There are so many things that can go wrong in such a long development process, without intermediate parts that will be immediately useful to the community, and so many assumptions that the community can/will follow. I have read many stories of failed software development efforts (I have a software engineering background) and this strategy document very strongly reminds me of these documents.
FWIW, I advocate a more gradual path, where as much as possible of the planned technologies are integrated step by step. This so that the community can follow and moreover benefit from the positive aspects of these technologies *immediately*, instead of having to wait for a long time for these technologies to arrive in a big-bang release (which typically also is an affair with a much higher chance of failure). I found that the image included in the original message (
https://i.imgflip.com/rl3g1.jpg) was not funny at all BTW. Added benefit of such an approach is that support for these technologies is then outsourced, which frees up time.
For example, why not migrate to protocol buffers as a start, to outsource that part of ROS? Migration for the community should be easy, it’s relatively trivial to write a tool that can convert .yaml files to .proto files and this tool could be included in ROS.
> On Sep 29, 2015, at 08:09, Michael Haberler via ros-users <ros-users@lists.ros.org> wrote:
>
> I think looking at a spec sheet alone for such a decision runs the danger of disregarding a key aspect of open source social dynamics: you might miss the buy-in of a key constituency and - given the lack of interoperability - in essence bifurcate the project, with a good chance of sinking the whole ship while at it:
>
> - a open-source-only variant which remains with ROS1 as DDS adoption is unlikely to happen
> - a ROS2/DDS flavor used by folks which face institutional pressures to adopt DDS
>
> If the hope for this project is 'Open Source Robotics', rather than 'a DDS sales channel', I think the decision is ill advised and flawed technically as well as socially. Changing middleware without a migration path is risky enough. While at it, going to a place where you stand a strong chance of loosing users along the way is extra divisive.
>
>
> I strongly recommend to revisit the ROS2/DDS decision:
>
> - put ROS-on-DDS on hold as just one option of several possibilities
> - proceed in parallel exploring alternatives based on actual use cases, actual measurements, and a more rigorous separation of concerns than shown so far
> - evaluate the cost of each one along several dimensions: fulfilling actual, proven-to-must-have requirements, integration effort, migration path, considering the upside of existing communities and their support contributions, and keep the factors for community buy-in in eyesight.
>
> - Michael
---> Save our in-boxes!
http://emailcharter.org <---
Johan Fabry -
http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
%20and%20this%20strategy%20document%20very%20strongly%20reminds%20me%20of%20these%20documents.%20%0A>%20%0A>%20FWIW,%20I%20advocate%20a%20more%20gradual%20path,%20where%20as%20much%20as%20possible%20of%20the%20planned%20technologies%20are%20integrated%20step%20by%20step.%20This%20so%20that%20the%20community%20can%20follow%20and%20moreover%20benefit%20from%20the%20positive%20aspects%20of%20these%20technologies%20*immediately*,%20instead%20of%20having%20to%20wait%20for%20a%20long%20time%20for%20these%20technologies%20to%20arrive%20in%20a%20big-bang%20release%20(which%20typically%20also%20is%20an%20affair%20with%20a%20much%20higher%20chance%20of%20failure).%20I%20found%20that%20the%20image%20included%20in%20the%20original%20message%20(https://i.imgflip.com/rl3g1.jpg)%20was%20not%20funny%20at%20all%20BTW.%20Added%20benefit%20of%20such%20an%20approach%20is%20that%20support%20for%20these%20technologies%20is%20then%20outsourced,%20which%20frees%20up%20time.%0A>%20%0A>%20For%20example,%20why%20not%20migrate%20to%20protocol%20buffers%20as%20a%20start,%20to%20outsource%20that%20part%20of%20ROS?%20Migration%20for%20the%20community%20should%20be%20easy,%20it%E2%80%99s%20relatively%20trivial%20to%20write%20a%20tool%20that%20can%20convert%20.yaml%20files%20to%20.proto%20files%20and%20this%20tool%20could%20be%20included%20in%20ROS.%0A>%20%0A>%20>%20On%20Sep%2029,%202015,%20at%2008:09,%20Michael%20Haberler%20via%20ros-users%20<ros-users@lists.ros.org>%20wrote:%0A>%20>%20%0A>%20>%20I%20think%20looking%20at%20a%20spec%20sheet%20alone%20for%20such%20a%20decision%20runs%20the%20danger%20of%20disregarding%20a%20key%20aspect%20of%20open%20source%20social%20dynamics:%20you%20might%20miss%20the%20buy-in%20of%20a%20key%20constituency%20and%20-%20given%20the%20lack%20of%20interoperability%20-%20in%20essence%20bifurcate%20the%20project,%20with%20a%20good%20chance%20of%20sinking%20the%20whole%20ship%20while%20at%20it:%0A>%20>%20%0A>%20>%20-%20a%20open-source-only%20variant%20which%20remains%20with%20ROS1%20as%20DDS%20adoption%20is%20unlikely%20to%20happen%0A>%20>%20-%20a%20ROS2/DDS%20flavor%20used%20by%20folks%20which%20face%20institutional%20pressures%20to%20adopt%20DDS%0A>%20>%20%0A>%20>%20If%20the%20hope%20for%20this%20project%20is%20'Open%20Source%20Robotics',%20rather%20than%20'a%20DDS%20sales%20channel',%20I%20think%20the%20decision%20is%20ill%20advised%20and%20flawed%20technically%20as%20well%20as%20socially.%20Changing%20middleware%20without%20a%20migration%20path%20is%20risky%20enough.%20While%20at%20it,%20going%20to%20a%20place%20where%20you%20stand%20a%20strong%20chance%20of%20loosing%20users%20along%20the%20way%20is%20extra%20divisive.%0A>%20>%20%0A>%20>%20%0A>%20>%20I%20strongly%20recommend%20to%20revisit%20the%20ROS2/DDS%20decision:%0A>%20>%20%0A>%20>%20-%20put%20ROS-on-DDS%20on%20hold%20as%20just%20one%20option%20of%20several%20possibilities%0A>%20>%20-%20proceed%20in%20parallel%20exploring%20alternatives%20based%20on%20actual%20use%20cases,%20actual%20measurements,%20and%20a%20more%20rigorous%20separation%20of%20concerns%20than%20shown%20so%20far%0A>%20>%20-%20evaluate%20the%20cost%20of%20each%20one%20along%20several%20dimensions:%20fulfilling%20actual,%20proven-to-must-have%20requirements,%20integration%20effort,%20migration%20path,%20considering%20the%20upside%20of%20existing%20communities%20and%20their%20support%20contributions,%20and%20keep%20the%20factors%20for%20community%20buy-in%20in%20eyesight.%0A>%20>%20%0A>%20>%20-%20Michael%0A>%20%0A>%20%0A>%20--->%20Save%20our%20in-boxes!%20http://emailcharter.org%20<---%0A>%20%0A>%20Johan%20Fabry%20%20%20-%20%20%20http://pleiad.cl/~jfabry%0A>%20PLEIAD%20and%20RyCh%20labs%20%20-%20%20Computer%20Science%20Department%20(DCC)%20%20-%20%20University%20of%20Chile%0A>%20%0A>%20_______________________________________________%0A>%20ros-users%20mailing%20list%0A>%20ros-users@lists.ros.org%0A>%20http://lists.ros.org/mailman/listinfo/ros-users%0A>%20 "Reply to this message")
(text/plain)