ROS2 strategy review

[Thibault Kruse]

Hi,

I prepared a wiki page where I tried to summarize my concerns about ROS2. I tried to give it the structure of a review, and I would be happy for others to edit the page boldly in good faith.

I prepared a claim-rebuttal structure to be able to provide a balanced view, but so far I did not rebut my own claims (I may try to, based on some answers already given in this forum, if nobody else wants to).

I intend to announce that page on ros-users in a week (this friday), so hopefully this gives other interested people enough time to contribute.

regards,
  Thibault

[Dirk Thomas]

Hi Thibault,

would you like to share the link to that wiki page?

Thanks,

- Dirk

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thibault Kruse]

So sorry, here it is:
http://wiki.ros.org/sig/NextGenerationROS/StrategyReview

[Robert Dean]

I agree that a tracked/managed documents like this are a good idea. It gets a bit hard to follow or remember the ros2 conversations.

I am concerned that the stated directions may result in discussion where two parties continue to talk past each other. Do we rely on moderators to deal with that problem? At this time I do not have a better recommendation.

On Sun, Sep 20, 2015 at 6:13 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

So sorry, here it is:
http://wiki.ros.org/sig/NextGenerationROS/StrategyReview

[Thibault Kruse]

If it becomes a problem, we can still think about solving it.

There were some discussions here, I see no problem with them:
http://wiki.ros.org/catkin/Reviews/2012-08-01_API_Review

[Vincent Rabaud]

Reading this wiki page, I see a lot of non-ROS related opinions that have triggered debates in other open source communities:
- should we break API gradually (KDE when upgrading Qt)
- should we impose changes (Gnome 3 and unity)
- should we rely on a "bad" license for a good technology (KDE1 vs Gnome; and BTW, we've mentioned Open-DDS and qeo as "good" license implementations)
- should we trust industries in their contributions (NVidia and its custom drivers, OpenCV and its mostly industrial contributions)
- should we target newer languages (gcc 5 and C++)
- ...

From what I've read in those other communities, there's is no right or wrong answer: it depends on its members, its motivation and it mostly evolves over time (gcc used to be open source with hidden development). Hence, I don't see the point of those rebuttals on the wiki page: there is no right or wrong.

Overall, it seems to me that ROS2 is managed more like the kernel by the Linux foundation, less like a pure community-based project like KDE. A good look at what we have is the next ROSCon program: several talks about ROS2 by people (OSRF or not) that indeed did not follow some of the suggestions on that wiki page (no REP for example) but that got some shit done.

Do I wish they had involved more people ? Hell yeah ! But resources are scarce and their time too.

Do I trust them ? Hell yeah, they've shown transparency from the beginning, they've promised an alpha by the end of the summer that they delivered, they've been around for a while in ROS1.

Do I wish more people could help like in KDE ? Hell yeah ! But the young ROS community is only in the 10K's of users and communication development most likely involves way less.

Where does that leave us ? Well, with people from the same ROS community with different opinions. What to do about it ? I believe, the common solutions are:
* fork (like mplayer and libav)

* create a crisis and get people to choose a side and leave if disagree (license in the kernel)

* ask the community to govern. Maybe I'm too French, but let's make a big survey, easy to answer, neutral enough:

     - do you trust OSRF to lead the ROS2 effort ?

     - are you willing to break API and maintain two communication codes ?

     - are you willing to adopt a modified catkin (ament) so that ROS2 works on windows, embedded ... ?

     - do you want a cathedral development model (with REP and such) or a bazaar one (with quicker iterations) ?
     - ...

* accept that the best does not necessarily involve the best code, practice and people: it's just what the community (users, companies) managed to put together at that time. Focus on the project/product and use your resources on ironing out the flow, not on fighting it to shape it differently, it's too late, for better or for worth.

Just like when I was a Willow employee, I'm still here for the fun, I'm here for the future of robotics, the future of my job but I now have very little free time to discuss common open source disagreements. Hence, I stand by the last option.

On that wiki page, to me, only point 3.3 and 4.4 are worth discussing. Other ones just seem like opinions and I agree to disagree.

Good luck ROS2 guys, whether you're from OSRF, PAL, on your own, I don't care. You've promised something, you've delivered so far, please continue.

On Sun, Sep 20, 2015 at 12:13 PM, Thibault Kruse <tibo...@googlemail.com> wrote:

So sorry, here it is:
http://wiki.ros.org/sig/NextGenerationROS/StrategyReview

[Thibault Kruse]

On Sunday, September 20, 2015 at 6:53:15 PM UTC+2, Vincent Rabaud wrote:

From what I've read in those other communities, there's is no right or wrong answer: it depends on its members, its motivation and it mostly evolves over time (gcc used to be open source with hidden development). Hence, I don't see the point of those rebuttals on the wiki page: there is no right or wrong.

I respect that opinion. Mostly I want to make sure the community at large is aware of what is going on. Everything else will happen depending on the community. I do not see a better way for me of informing the community.

[Thibault Kruse]

On Sunday, September 20, 2015 at 6:53:15 PM UTC+2, Vincent Rabaud wrote:

On that wiki page, to me, only point 3.3 and 4.4 are worth discussing. Other ones just seem like opinions and I agree to disagree.

Do you permit that I add your name to those points? This could work a bit like a poll, to see which concerns are most interesting to the community.

[Dirk Thomas]

Hi Thibault,

it might be that I misread the tone in this document since English is not my native language.

But from my personal point of view the whole page has a very negative / accusatory attitude which I don't think this is appropriate.

Especially if you expect the page to serve as an objective "strategy review".

Beside that I have a few comments regarding the "15 facts" at the top of the wiki page.

> 1. ROS2 uses DDS-implementations as the communication layer, this decision has been announced #ros2announce, #ros2query

ROS 2 is not tied to DDS.

The ROS middleware interface (RMW) is a C API which can be implemented by any backend.

It is specifically designed to be DDS agnostic even while it is inspired by the feature set of DDS.

Currently there are only DDS-based implementation and OSRF does not plan to develop other backends in the foreseeable future.

Btw. there is a ROS 2 article about exactly this which should be referenced here.

> 2. ROS2 selects one of several DDS implementations at compile time (C++, ...) or runtime (Python, ...)

The selection of the RMW implementation happens for C++ at link time - not at compile time.

This is also mentioned in a ROS 2 article and should be referenced.

> 3. The only DDS implementation with a standard Open-Source license is OpenSplice, which however has seen only 3 commits in the last 12 months, and less than 50 in the last 4 years (#OpenhubOpenSplice)

The quoted statistics are meaningless since PrismTech only pushes their released code into that GitHub repository.

Their development does not happen in a public repository.

While that is not a great thing I don't think the statistics are of any relevance - it is similar to a statistic of a GBP / release repository in ROS 1.

> 4. OSRF still negotiates with RTT Connext over providing a suitable open-source license, a non-standard free-for-research license is available #ros2announce

We can't tell you anything about ou bidirectional communication with companies like RTI.

But the chances are that there will be another proven DDS implementation with an OSI approved license in the future.

Another alternative which you did not mention is the implementation from eProsima.

* https://github.com/eProsima/Fast-CDR

* https://github.com/eProsima/Fast-RTPS

* https://github.com/eProsima/ROS-RMW-Fast-RTPS-cpp

While we are still working with them so seemlessly interoperate with the other vendors it looks like a promising alternative to the "big established players".

An then there is the current work on FreeRTPS done by Morgan which implements the basic protocols in pure C for micro controllers.

> 5. DDS provides no request-response, only something similar to actionlib

DDS does have a request/response specification (http://www.omg.org/spec/DDS-RPC/) and most vendors already implement (part of) the standard.

The ROS 2 alpha 1 release already provide a request / response API very similar to the one available in ROS 1.

I don't see how this is similar to actionlib though.

> 6. ROS2 core packages and tool support sources are completely separated from ROS1 sources

The rational for this decision as well as the pros and cons have been discussed in very detail and are summarized in an article.

> 7. The ROS2 client API is not backwards compatible with ROS1

> 8. The ROS2 build tool (ament) is not backwards compatible with catkin

> 9. All message definition packages are being duplicated as ROS2 packages

> 12. ROS2 defines different language baselines than ROS1 (Python3, C++11)

All of these have been discussed in lengthy detail on the mailing list in the last months.

A lot of arguments have been mentioned there and I simple don't want to reiterate them here.

Also a lot of options have been suggested to mitigate the effort necessary when migrating from ROS 1 to ROS 2.

Please link to the past discussions here.

> 10. Some message definitions differ between ROS1 and ROS2 in name and structure

Please be specific and enumerate the messages and types which do differ and also describe how they are different.

> 13. OSRF members have claimed that ROS2 targets industry users first, and academia second

The major goal of ROS 2 is to address shortcomings of the ROS 1 design.

Support for Windows, support for embedded systems, support for multi robot system via wireless, more deterministic behavior to name a few.

While a lot of these use cases are relevant for industrial applications that does not mean that academia is only a second level community for ROS 2.

I am pretty sure that a lot of ROS 1 users from academia will be eager to have some of the ROS 2 features available.

> 14. OSRF members claim that ROS1 will continue to be released for a long time

Both systems ROS 1 and ROS 2 will coexist for quite a while.

Phrase it to be "a claim of OSRF members" implies a very different thing here.

Please rephrase this in an objective way.

> 15. No REP, not even in draft form, has been created for any ROS2 feature

Clearly there is a lot of documentation about the ROS 2 design.

Are the documents called REPs? No, but the existing articles serve a similar purpose.

Could there be more? Of course, there is always room for more documentation.

On several of them a lot of discussion is actively going on: e.g.

* node life cycle https://github.com/ros2/design/pull/34

* parameters https://github.com/ros2/design/pull/58

Maybe those should be mentioned here too in order to not only show your perspective here.

Thanks,

- Dirk

On Sun, Sep 20, 2015 at 3:13 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

So sorry, here it is:
http://wiki.ros.org/sig/NextGenerationROS/StrategyReview

[Thibault Kruse]

Hi Dirk,

On Monday, September 21, 2015 at 5:50:59 AM UTC+2, Dirk Thomas wrote:

Hi Thibault,

it might be that I misread the tone in this document since English is not my native language.

But from my personal point of view the whole page has a very negative / accusatory attitude which I don't think this is appropriate.

Especially if you expect the page to serve as an objective "strategy review".

I tried for some neutral tone, I can try harder, but in the end a review will mostly list flaws, that's the whole point of any review. And a long list of flaws will commonly suggest a negative attitude. There is only so much that can be done about that.

I am sure if you wrote such a lists, some people might say it has a positively biased tone. This is why I think a wiki page and the claim/rebuttal structure can balance out the review tone, and why I left a week for some iterations.

As I said, I am very open to bold changes to the wiki page to approach a neutral tone, though perfection might not be achieved.

Beside that I have a few comments regarding the "15 facts" at the top of the wiki page.

> 1. ROS2 uses DDS-implementations as the communication layer, this decision has been announced #ros2announce, #ros2query

ROS 2 is not tied to DDS. ...

Btw. there is a ROS 2 article about exactly this which should be referenced here.

Added the word "default" and added link.
 

The selection of the RMW implementation happens for C++ at link time - not at compile time.

This is also mentioned in a ROS 2 article and should be referenced.

changed and added link

> 3. The only DDS implementation with a standard Open-Source license is OpenSplice, which however has seen only 3 commits in the last 12 months, and less than 50 in the last 4 years (#OpenhubOpenSplice)

The quoted statistics are meaningless since PrismTech only pushes their released code into that GitHub repository.

Their development does not happen in a public repository.

While that is not a great thing I don't think the statistics are of any relevance - it is similar to a statistic of a GBP / release repository in ROS 1.

Looking at the contents of commits, several (of these very few) change only very small things (e.g. the only commit in 2015 is the addition of a README file, with one sentence of text). So I think there is still some relevance to it, but I reformulated.

> 4. OSRF still negotiates with RTT Connext over providing a suitable open-source license, a non-standard free-for-research license is available #ros2announce

We can't tell you anything about our bidirectional communication with companies like RTI.

But the chances are that there will be another proven DDS implementation with an OSI approved license in the future.

I think that is what I said in the fact, right?
 

Another alternative which you did not mention is the implementation from eProsima.

Added, refuted claim.
 

> 5. DDS provides no request-response, only something similar to actionlib

DDS does have a request/response specification (http://www.omg.org/spec/DDS-RPC/) and most vendors already implement (part of) the standard.

The ROS 2 alpha 1 release already provide a request / response API very similar to the one available in ROS 1.

I don't see how this is similar to actionlib though.

I thought the DDS req/resp works over topic messages (non-blocking) and allows for long-running services. I cannot tell whether this makes actionlib obsolete or not. If someone can provide a short statement about the relationship of ROS1 services, actionlib, and DDS services, that would help.

> 6. ROS2 core packages and tool support sources are completely separated from ROS1 sources

The rational for this decision as well as the pros and cons have been discussed in very detail and are summarized in an article.

I cannot find the article, if you provide the link I can add it.
 

> 7. The ROS2 client API is not backwards compatible with ROS1

> 8. The ROS2 build tool (ament) is not backwards compatible with catkin

> 9. All message definition packages are being duplicated as ROS2 packages

> 12. ROS2 defines different language baselines than ROS1 (Python3, C++11)

All of these have been discussed in lengthy detail on the mailing list in the last months.

A lot of arguments have been mentioned there and I simple don't want to reiterate them here.

Also a lot of options have been suggested to mitigate the effort necessary when migrating from ROS 1 to ROS 2.

Please link to the past discussions here.

That's fine, I can add links, maybe I will try to summarize the rebuttals. I'll do that before friday and notify when it's ready for review.

> 10. Some message definitions differ between ROS1 and ROS2 in name and structure

Please be specific and enumerate the messages and types which do differ and also describe how they are different.

I can try to give examples, though I don't have a complete overview, and I am not sure who has. I also assume this is prone to change a lot.

> 13. OSRF members have claimed that ROS2 targets industry users first, and academia second

The major goal of ROS 2 is to address shortcomings of the ROS 1 design.

Support for Windows, support for embedded systems, support for multi robot system via wireless, more deterministic behavior to name a few.

While a lot of these use cases are relevant for industrial applications that does not mean that academia is only a second level community for ROS 2.

I am pretty sure that a lot of ROS 1 users from academia will be eager to have some of the ROS 2 features available.

I will add links to the relevant posts in the discussions. I still removed the academia bit.

> 14. OSRF members claim that ROS1 will continue to be released for a long time

Both systems ROS 1 and ROS 2 will coexist for quite a while.

Phrase it to be "a claim of OSRF members" implies a very different thing here.

Please rephrase this in an objective way.

This was not meant to imply hidden intentions.

> 15. No REP, not even in draft form, has been created for any ROS2 feature

Clearly there is a lot of documentation about the ROS 2 design.

Are the documents called REPs? No, but the existing articles serve a similar purpose.

I tried to explain in the claim the difference between a REP and a documentation. I now added more details, and added a short rebuttal, mentioning discussions at github.

Thanks for the review-review.

[Thibault Kruse]

BTW: I added eProsima to OpenHub to analyze / track activity:
https://www.openhub.net/p/eprosima

[Tully Foote]

Hi Thibault, 

Looking through the page it appears that there are several areas in which you would like more information or would like to suggest a different approach. You have called out 15 specific items which you'd like to talk about. Some of them have already been talked about on this list. But presenting them as "the following facts about ROS2 can be reviewed" is very misleading. We don't need to have an investigation of facts for an open source project with open design documents, open issue trackers, and an open mailing list.

We want to answer everyone's questions as well as hear everyone's feedback on our design, process, and products. Especially with the ROS 2.0 effort we've worked hard to be transparent with our design and decision making process by posting articles on the design website. Every decision has tradeoffs and we work hard to reach the best solution possible given all our inputs and constraints.

If there are areas you are not sure about or would like more information, please just ask a question. If there is something you'd like done differently, please make a suggestion.

This mailing list is the best forum for this. This mailing list is publicly archived and has over 200 people subscribed who have actively chosen to listen to the ongoing ROS 2.0 discussions. As we've already been doing, discussions here can always transition into tracker issues or pull requests and if they get to general on a specific issue, they can move back here for more general discussions.

Tully

Resources: 

ROS 2.0 design website: http://design.ros2.org/ 

ROS 2.0 source code + issue trackers: https://github.com/ros2

Mailing list: https://groups.google.com/forum/#!forum/ros-sig-ng-ros

On Mon, Sep 21, 2015 at 6:20 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

BTW: I added eProsima to OpenHub to analyze / track activity:
https://www.openhub.net/p/eprosima

--

[Thibault Kruse]

Hi Tully,

On Monday, September 21, 2015 at 10:53:00 PM UTC+2, Tully Foote wrote:

Hi Thibault, 

Looking through the page it appears that there are several areas in which you would like more information or would like to suggest a different approach.

That's not the point of that page. You might have noticed I did ask questions and suggested different approaches over the last couple of weeks, in this forum. If I have more questions / suggestions, I continue doing that.

The aim of the review page is to make the community at large aware of the major decisions OSRF has made and how this will potentially impact everybody. Call it journalism, if you like.

But presenting them as "the following facts about ROS2 can be reviewed" is very misleading.

The review page needs to be somewhat self-sustained, IMO. I am open about differently labelling the list of things that represent the strategy to be reviewed.
The ROS2 strategy is difficult to pinpoint, so "observables" are my best handle to the strategy.

We don't need to have an investigation of facts for an open source project with open design documents, open issue trackers, and an open mailing list.

Who is "we"? (look at your next sentence to see why "we" is ambiguous)
 

We want to answer everyone's questions as well as hear everyone's feedback on our design, process, and products. Especially with the ROS 2.0 effort we've worked hard to be transparent with our design and decision making process by posting articles on the design

website.

I know. And I am trying to get you even more feedback from *everyone*.

Every decision has tradeoffs and we work hard to reach the best solution possible given all our inputs and constraints.

Best for whom?
To me it seems that in several cases when there was a tradeoff to be made between effort for OSRF and effort for the community,  OSRF has made those decisions without asking or informing the community at large. ament being one example.

This mailing list is the best forum for this. This mailing list is publicly archived and has over 200 people subscribed who have actively chosen to listen to the ongoing ROS 2.0 discussions.

Indeed, for questions about ROS2.0 I would choose this mailing list. To *inform* the community at large about what is being planned to change their future jobs significantly, ros-users seems like the right place to me.

[Jack O'Quin]

Thibault:

While I personally agree with some of the points you raise, your overall rhetoric still sounds quite overheated. I respect your opinions and readily grant you the "assumption of good faith"[1], but would like to suggest toning down some of the words. (I see some cooling down since yesterday, for which I thank you.)

 [1] http://wiki.ros.org/Support#Etiquette
​

1.1, 1.2, 5.5 To my ears (USA deep-South dialect), the word "schism" suggests the bloody European wars of religion of the 16th and 17th centuries. That seems excessive in the context of a system software engineering discussion. 

If I understand correctly, you use it because you object strongly to the decision of fork several of the ROS 1 core modules, instead of building ROS 2 as a branch in the original repositories. Reasonable people can agree or disagree about that, but calling it a "fork" rather than a "schism" seems a better way to focus that discussion.

3.1 Parallel maintenance causes high effort / low quality

How about "Parallel maintenance looks hard"?

3.2 ROS2 improvements will not be backported to ROS1 (e.g. ament)

I don't remember anyone saying ament will never be backported to ROS 1. The discussion I recall was that no one wants to think about doing it right now. It might very well be done at some point, after the implementation becomes more mature.

Thanks for your passion and dedication to ROS,

[Bill Morris]

On 09/23/2015 05:42 PM, Jack O'Quin wrote:
> Thibault:
>
> While I personally agree with some of the points you raise, your overall
> rhetoric still sounds quite overheated. I respect your opinions and readily
> grant you the "assumption of good faith"[1], but would like to suggest
> toning down some of the words. (I see some cooling down since yesterday,
> for which I thank you.)
>
> [1] http://wiki.ros.org/Support#Etiquette

I also agree with some of Thibault's sentiment and points, however I
think OSRF also deserves an assumption of good faith as well.
I would like to see us work towards consensus instead of conflict.

> 1.1, 1.2, 5.5 To my ears (USA deep-South dialect), the word "schism"
> suggests the bloody European wars of religion of the 16th and 17th
> centuries. That seems excessive in the context of a system software
> engineering discussion.
>
> If I understand correctly, you use it because you object strongly to the
> decision of fork several of the ROS 1 core modules, instead of building ROS
> 2 as a branch in the original repositories. Reasonable people can agree or
> disagree about that, but calling it a "fork" rather than a "schism" seems a
> better way to focus that discussion.
>
> 3.1 Parallel maintenance causes high effort / low quality
>
> How about "Parallel maintenance looks hard"?

I would also note that this seems like a bounded problem. It looks to me
that parallel maintenance should increase developer workload 25-110%
This is probably solvable by increasing the the number of active
developers or by moving many packages from 'development' to
'maintenance' or 'inactive'
Being able to reuse messages should help with this.

> 3.2 ROS2 improvements will not be backported to ROS1 (e.g. ament)
>
> I don't remember anyone saying ament will never be backported to ROS 1. The
> discussion I recall was that no one wants to think about doing it right
> now. It might very well be done at some point, after the implementation
> becomes more mature.

I think it is important to note that this is primarily a resource
contention problem not a technical or policy decision as far as I can tell.
If more companies that using ROS commercially support OSRF, then there
will be more resources for backporting changes when they are mature.

Personally, I know I would love to be spending more time supporting open
source software, but my day job does not currently prioritize publishing
code.
Unfortunately, I don't think I am alone here.

>
> Thanks for your passion and dedication to ROS,
>

+1

[Thibault Kruse]

On Wednesday, September 23, 2015 at 11:42:05 PM UTC+2, Jack O'Quin wrote:

1.1, 1.2, 5.5 To my ears (USA deep-South dialect), the word "schism" suggests the bloody European wars of religion of the 16th and 17th centuries.

I had no idea. I rephrased to forks. It might not be a perfect word, but it'll do.

3.1 Parallel maintenance causes high effort / low quality

How about "Parallel maintenance looks hard"?

done.
 

3.2 ROS2 improvements will not be backported to ROS1 (e.g. ament)

I don't remember anyone saying ament will never be backported to ROS 1. The discussion I recall was that no one wants to think about doing it right now. It might very well be done at some point, after the implementation becomes more mature.

I am sure with unlimited time and budget anything might very well be done at some point. That's the difference between good faith and unbounded optimism.

I changed that section a bit, added a refutal.

[Thibault Kruse]

On Thursday, September 24, 2015 at 12:16:11 AM UTC+2, Bill Morris wrote:

I would also note that this seems like a bounded problem. It looks to me
that parallel maintenance should increase developer workload 25-110%
This is probably solvable by increasing the the number of active
developers or by moving many packages from 'development' to
'maintenance' or 'inactive'
Being able to reuse messages should help with this.

I don't know where you see any potential for more active developers, in particular for doing additional tasks that do not increase the ROS value (providing the same feature for multiple middlewares, instead of adding new features).

Making more packages become inactive surely "solves" this, but somehow I fail to see how packages becoming unmaintained is great for ROS users.

Maybe you have non-public packages used inside companies in mind. If a company does not rely on open-source packages (other than core), then this may not be a problem in industry (I put that in the refutal). But it is a problem in academia. And it affects ROS1 users.

> 3.2 ROS2 improvements will not be backported to ROS1 (e.g. ament)
>
> I don't remember anyone saying ament will never be backported to ROS 1. The
> discussion I recall was that no one wants to think about doing it right
> now. It might very well be done at some point, after the implementation
> becomes more mature.  

I think it is important to note that this is primarily a resource
contention problem not a technical or policy decision as far as I can tell.
If more companies that using ROS commercially support OSRF, then there
will be more resources for backporting changes when they are mature.

I added the last bit to the rebuttal.

It does not convince me as I believe by relying on shared libraries between ROS1 and ROS2, and staying backwards compatible even with some warts, the overall costs in the community would be reduced. And if additional resources for open-source work became available anywhere in the ROS ecosystem, it could into more useful areas than crossporting across completely separated codebases.

[Bill Morris]

On 09/24/2015 06:06 AM, Thibault Kruse wrote:
> On Thursday, September 24, 2015 at 12:16:11 AM UTC+2, Bill Morris wrote:
>> I would also note that this seems like a bounded problem. It looks to me
>> that parallel maintenance should increase developer workload 25-110%
>> This is probably solvable by increasing the the number of active
>> developers or by moving many packages from 'development' to
>> 'maintenance' or 'inactive'
>> Being able to reuse messages should help with this.
>>
> I don't know where you see any potential for more active developers,

We can do better at training new developers. Improving documentation,
and making ROS more accessible.

Perhaps, open source development could be integrated into a industry
certification/training program. ie. each person working to become a
"Certified ROS Developer" would be expected to go through the process of
submitting pull requests to improve ROS.

Can we make opportunities for professional roboticists to contribute
more to ROS? One idea, which may be completely impractical, would be to
have a sabbatical program for engineers working in industry to work on
ROS2 at OSRF or a nearby university for a month.

Can companies sponsor a full-time staff position at OSRF?

> in
> particular for doing additional tasks that do not increase the ROS value
> (providing the same feature for multiple middlewares, instead of adding new
> features).

Of course supporting multiple middlewares does not add value to most of
our work, however it appears critical for some applications. I
personally want an opensource middleware with active open development,
but I am pretty sure NASA/ESA and others need a "flight certified"
middleware and are less picky about licensing agreements. Also, I think
this line of reasoning is why ROS initially used every possible version
control system. For better or worse, there are many applications where
ROS1 can not meet safety requirements.

My guess is that at some point OSRF is going to pick one opensource
middleware as the default and everyone who doesn't have to worry about
safety certifications will use that. I don't think it is a waste of time
to support the capability to use alternate middleware, but I do agree
that maintaining support for multiple middleware vendors is not
something OSRF should be spending time on. It seems to me that the
middleware vendors themselves should be maintaining that code.

> Making more packages become inactive surely "solves" this, but somehow I
> fail to see how packages becoming unmaintained is great for ROS users.

Marking a package as "unmaintained" lets new developers know that the
package could use a maintainer.
Unmaintained packages are not great for the ROS community but we need to
find a reasonable set of compromises to move forward.

> Maybe you have non-public packages used inside companies in mind. If a
> company does not rely on open-source packages (other than core), then this
> may not be a problem in industry (I put that in the refutal). But it is a
> problem in academia. And it affects ROS1 users.

As a package maintainer I'm really concerned about seeing my workload
double during the transition period.
I think this is probably the strongest point against a long transition
from ROS1 to ROS2.

I don't really see how a working ROS1 to ROS2 bridge will significantly
reduce work for active package maintainers.
ex. Even with a bridge I would probably need to maintain two code bases
for computer vision tasks given the likely changes to cv_bridge, image
infrastructure and etc.
Maybe there is a way to get a single codebase by building ROS2 nodes
that can speak ROS1 rostcp and use ROS1 message types?
Are there ways we can move forward with an incremental approach? Is
there a set of features we can define as ROS1.5 such that we can support
ROS1.5 and ROS2 from a single code base?
What compromises would allow us to work towards the features of ROS2
without doubling our workload?

Developer time is probably our most limited resource, so I agree that
the entire ROS community should be aware of the implications of a
multi-year transition from ROS1 to ROS2.
I am not excited about a slow migration to ROS2 and would probably
prefer to deprecate ROS1 and focus on ROS2 if we as a community are
serious about it.
If we don't support something like ROS2, I believe we risk
(theoretical?) closed source forks of ROS1 + DDS.

>
>> 3.2 ROS2 improvements will not be backported to ROS1 (e.g. ament)
>>> I don't remember anyone saying ament will never be backported to ROS 1.
>> The
>>> discussion I recall was that no one wants to think about doing it right
>>> now. It might very well be done at some point, after the implementation
>>> becomes more mature.
> I think it is important to note that this is primarily a resource
>> contention problem not a technical or policy decision as far as I can
>> tell.
>> If more companies that using ROS commercially support OSRF, then there
>> will be more resources for backporting changes when they are mature.
>>
> I added the last bit to the rebuttal.
>
> It does not convince me as I believe by relying on shared libraries between
> ROS1 and ROS2, and staying backwards compatible even with some warts, the
> overall costs in the community would be reduced. And if additional
> resources for open-source work became available anywhere in the ROS
> ecosystem, it could into more useful areas than crossporting across
> completely separated codebases.

Let me try rephrasing, If commercial applications are the primary
beneficiary of ROS2, then the companies that need ROS2 should be capable
of funding enough open source developers to maintain both codebases if
that is the transition plan necessary to get to ROS2. Personally, I
would love to get paid to contribute to open source all day, but I still
have not managed to find a way to make that work, yet.

[Thibault Kruse]

On Friday, September 25, 2015 at 6:59:13 AM UTC+2, Bill Morris wrote:

>  in
> particular for doing additional tasks that do not increase the ROS value
> (providing the same feature for multiple middlewares, instead of adding new
> features).
Of course supporting multiple middlewares does not add value to most of

our work, however it appears critical for some applications. ...

My guess is that at some point OSRF is going to pick one opensource
middleware as the default and everyone who doesn't have to worry about
safety certifications will use that.

I was still mostly talking about OSRF having to support both ROS1 and ROS2, each having completely separate codebases and problems. The same effort exists for the community at large. Supporting multiple DDS vendors makes this even harder indeed. And the only way OSRF could dictate a default is by removing the ability from ament to choose a DDS vendor. Else, the community will split into sub-communities using different favored vendors, and package maintenance will involve testing against multiple vendors. But again, the first problem is to support ROS1 and ROS2 in parallel.

> Making more packages become inactive surely "solves" this, but somehow I
> fail to see how packages becoming unmaintained is great for ROS users.
Marking a package as "unmaintained" lets new developers know that the
package could use a maintainer.
Unmaintained packages are not great for the ROS community but we need to
find a reasonable set of compromises to move forward.

That's also a more complicated problem, because packages in the future might become "unmaintained", "unmaintained in ROS1 only", and "unmaintained in ROS2 only". Because supporting both ROS1 and ROS2 is a strong effort that many maintainers will not be willing to invest. A typical maintainer uses just one of ROS1 or ROS2 in their day-job, and responding to bug reports by reproducing locally and creating a new release will only fit into their free time with one of ROS1 and ROS2.

I don't even know yet how slow package migration will work. For any given package, will there be two packages per ROS distribution with the same name, e.g. sharing a ROS wiki page? Or will package maintainers have to choose to only be released with either ROS1 or ROS2? Or will the package have to be named differently? If there are two packages of the same name, how will that affect build tools and other tools (like rospkg)? Will all maintainers do this consistently, or each one picking a different alternative?

All of those are nasty compromises having drawbacks. The alternative that each ROS distribution has exactly one package of a name that is not duplicated across ROS1 and ROS2 but that can (somehow) be used with both ROS1 and ROS2 was not considered viable by OSRF (because ROS1 could break, or more effort to prevent this, ROS2 might be delayed...).

> Maybe you have non-public packages used inside companies in mind. If a
> company does not rely on open-source packages (other than core), then this
> may not be a problem in industry (I put that in the refutal). But it is a
> problem in academia. And it affects ROS1 users.
As a package maintainer I'm really concerned about seeing my workload
double during the transition period.
I think this is probably the strongest point against a long transition
from ROS1 to ROS2.

Indeed, but since so much of ROS2 is created from scratch, avoiding a long transition period seems impossible.

I don't really see how a working ROS1 to ROS2 bridge will significantly
reduce work for active package maintainers.

Me neither. The whole interop story is prone to eat up much more time than "merely" providing a package for both ROS1 and ROS2, I believe.
 

Is there a set of features we can define as ROS1.5 such that we can support
ROS1.5 and ROS2 from a single code base?

What compromises would allow us to work towards the features of ROS2
without doubling our workload?

 

I tried suggesting that somewhere else. It would mean making ament be able to build ROS1 and ROS2 packages, keeping the message packages unique and mixing ROS1 and ROS2 message generators (establishing ugly cross dependencies and having risks of breakage in ROS1). OSRF categorically excluded this way from the start ("ROS1 will not break"), and OSRF made this way much harder by creating completely separate sources for all the tooling.

I don't see another way for a ROS1.5.

[Brian Gerkey]

On Thu, Sep 24, 2015 at 9:59 PM, Bill Morris <bi...@neautomation.com> wrote:

> Can companies sponsor a full-time staff position at OSRF?

Absolutely! In fact, there's a Bosch-funded position open now:

http://www.bosch.us/content/language1/html/13896.htm

[Jonathan Bohren]

@gerkey @tfoote Is there a concrete ROS mission statement and a well-defined breakdown of target users / market segments which motivate where ROS development is focused?

[Brian Gerkey]

On Mon, Sep 28, 2015 at 2:35 PM, Jonathan Bohren
<jonatha...@gmail.com> wrote:
> @gerkey @tfoote Is there a concrete ROS mission statement and a well-defined
> breakdown of target users / market segments which motivate where ROS
> development is focused?

OSRF's mission statement (which is legally binding, btw) is "to
support the development, distribution, and adoption of open source
software for use in robotics research, education, and product
development." (http://www.osrfoundation.org/about/)

We don't have a separate statement for any specific development effort
(ROS, Gazebo, CloudSim, etc.).

[Jonathan Bohren]

On Mon, Sep 28, 2015 at 5:37 PM Brian Gerkey <ger...@osrfoundation.org> wrote:

OSRF's mission statement (which is legally binding, btw) is "to
support the development, distribution, and adoption of open source
software for use in robotics research, education, and product
development." (http://www.osrfoundation.org/about/)

We don't have a separate statement for any specific development effort
(ROS, Gazebo, CloudSim, etc.).

At least Gazebo and CloudSim have a pretty well-defined scope, even though Ignition Robotics seems to be less-constrained and even appears to be developing as a ROS alternative.

However, building feature X for ROS, no matter what X is, satisfies "support[ing] the development... of open source software for use in robotics," but are there more specific guiding principles or tests that could inform what feature X should be?

Some of these have come out in various contexts, but still aren't very clear to me. For example, in the ROS LIVE chat that happened back in August, one of the design "goals" for ROS2 is that "ROS1 and ROS2 should not share any code" but this sounds more like a possible solution to the goal that "ROS2 development should not disrupt ROS1 operation."

I think one thing that's struck me while reading the discussions surrounding ROS2 is that I don't even know what ROS2 is trying to accomplish beyond the specifics of what's being re-implemented. I understand ROS2 is supposed to resolve a lot of the software architecture concerns about the way ROS1 is implemented; I understand that the transport layer is supposed to be more powerful; and I understand that it will provide more options for code composition and modularity.

What's unclear to me is that after these changes and the huge migration effort, will it enable us to make robots do things that were previously unfeasible within the design constraints of ROS1, even when utilizing other software libraries and extensions developed by the broader community? Alternatively, will it make it easier to make robots do the things that they can already do?

-j

[Esteve Fernandez]

Hi

On Mon, Sep 28, 2015 at 3:44 PM, Jonathan Bohren
<jonatha...@gmail.com> wrote:
> What's unclear to me is that after these changes and the huge migration
> effort, will it enable us to make robots do things that were previously
> unfeasible within the design constraints of ROS1, even when utilizing other
> software libraries and extensions developed by the broader community?
> Alternatively, will it make it easier to make robots do the things that they
> can already do?

with ROS2 we want to reach a broader audience while making it possible
to support the current use cases of ROS1. And by broader audience I
don't only mean the industry, but also more users in academia. For
example, right now you can operate drones with ROS1, but the whole
experience is less than optimal, you can't control QoS, ROS1 is
sometimes too big for small devices, impossibly huge for
microcontrollers, etc. And of course, ROS1's supported platforms are
basically just one: Linux. We want to reach users of other platforms,
such as Windows and OSX. Reengineering ROS1 to support all these cases
might be feasible, but requires so many changes that it might be just
better to use that opportunity to modernize ROS (e.g. C++11/14, make
ROS more modular, etc.) and get rid of some technical debt.

Cheers.

[Steven Peters]

There is a design document that lays out some of the motivation for ROS 2.0:

http://design.ros2.org/articles/why_ros2.html

It's possible that there isn't enough detail there. For example, the bullet point about "Non-ideal networks" doesn't mention specific examples I have heard about problems with sending messages larger than a UDP datagram on a lossy wifi network. If you use TCP, things get congested, but if you use UDP you'll likely never actually receive all the datagrams from a single message, so you receive nothing.

Would extra detail in that article be helpful?

Steve

[Jonathan Bohren]

On Tue, Sep 29, 2015 at 12:42 PM, Steven Peters <scpe...@osrfoundation.org> wrote:

There is a design document that lays out some of the motivation for ROS 2.0:

http://design.ros2.org/articles/why_ros2.html

It's possible that there isn't enough detail there. For example, the bullet point about "Non-ideal networks" doesn't mention specific examples I have heard about problems with sending messages larger than a UDP datagram on a lossy wifi network. If you use TCP, things get congested, but if you use UDP you'll likely never actually receive all the datagrams from a single message, so you receive nothing.

Would extra detail in that article be helpful?

I'm very familiar with the current limitations of the ROS transport layer (and other aspects of ROS) as well as the ROS2 design documents. If I hadn't read these documents, I wouldn't be posting to this mailing list.

OSRF has done a great job at describing in great detail the problems with ROS1. What I don't understand is how the problems with ROS1 lead to the decision that ROS2 should be re-written from scratch. With respect to enhancing ROS1 instead of the current ROS2 plan, the "Why ROS2?" document states:

We considered this option and concluded that, given the intrusive nature of the changes that would be required to achieve the benefits that we are seeking, there is too much risk associated with changing the current ROS system that is relied upon by so many people.

This is a pretty major decision that is stated here without any analysis of where the risk is coming from. 

The plan that is currently being pursued (i.e. to re-implement all of ROS) will mean that in order to migrate, they will need to migrate their entire system. Furthermore, not being able to change only one thing at a time will make it hard to debug issues that arise from the migration. So, I'm still trying to understand the guiding philosophy that lead to this decision.

For example, how is fixing the transport layer too "intrusive" and why would it involve too much risk? I've mentioned this before, but for the transport, instead of re-writing everything, why not make a DDS-based transport layer available for all major client libraries. ROS1 could be given a DDS transport plugin (call it "DDSROS") and similar capabilities could be added to rospy and rosjava.

At the same time, OSRF can continue to develop "rclc" and the experimental "rclcpp" implementation which could be used alongside roscpp to also use this transport layer, but with a "modernized" API. Maybe instead of making this completely separate from roscpp, it could be put in the same library under the `ros::future` namespace or something along those lines. This is where support for all the new ROS infrastructure could but put and rolled in gradually. Similar functionality could be done with a `rospy.future` module.

Really, ROS2 as it is currently being developed is more of a ROS competitor than a second version. I'm also still curious about how Ignition Robotics fits into all of this. Is it also a ROS competitor?

-j

[Steven Peters]

Sorry I misunderstood your question.

OSRF has done a great job at describing in great detail the problems with ROS1. What I don't understand is how the problems with ROS1 lead to the decision that ROS2 should be re-written from scratch. With respect to enhancing ROS1 instead of the current ROS2 plan, the "Why ROS2?" document states:

We considered this option and concluded that, given the intrusive nature of the changes that would be required to achieve the benefits that we are seeking, there is too much risk associated with changing the current ROS system that is relied upon by so many people.

This is a pretty major decision that is stated here without any analysis of where the risk is coming from. 

The plan that is currently being pursued (i.e. to re-implement all of ROS) will mean that in order to migrate, they will need to migrate their entire system. Furthermore, not being able to change only one thing at a time will make it hard to debug issues that arise from the migration. So, I'm still trying to understand the guiding philosophy that lead to this decision.

The ROS 1 bridge is intended to help mitigate the migration challenges, so that you can run existing ROS 1 code alongside ROS 2. I don't think migration has to happen all at once.
https://github.com/ros2/ros1_bridge/blob/master/README.md

For example, how is fixing the transport layer too "intrusive" and why would it involve too much risk? I've mentioned this before, but for the transport, instead of re-writing everything, why not make a DDS-based transport layer available for all major client libraries. ROS1 could be given a DDS transport plugin (call it "DDSROS") and similar capabilities could be added to rospy and rosjava.

At the same time, OSRF can continue to develop "rclc" and the experimental "rclcpp" implementation which could be used alongside roscpp to also use this transport layer, but with a "modernized" API. Maybe instead of making this completely separate from roscpp, it could be put in the same library under the `ros::future` namespace or something along those lines. This is where support for all the new ROS infrastructure could but put and rolled in gradually. Similar functionality could be done with a `rospy.future` module.

I'll defer answering these questions to someone more knowledgeable.

Really, ROS2 as it is currently being developed is more of a ROS competitor than a second version. I'm also still curious about how Ignition Robotics fits into all of this. Is it also a ROS competitor?

Ignition Robotics is more closely related to Gazebo than ROS at the moment. Gazebo has been monolithic, with its own libraries for math, transport, etc. We have been splitting these libraries out, and they have been rebranded as Ignition Robotics libraries, in case non-Gazebo software is interested in using it but would be put off by the Gazebo name. I wouldn't name it as a ROS competitor.

I imagine the ignition-transport library is the piece that prompted the question? That library is mainly a rewrite of gazebo's custom transport layer. One difference is that the Ignition Robotics libraries can follow FHS by installing to /usr, which is a requirement for gazebo (unlike ROS, which is currently in /opt).

Steve

-j

--
You received this message because you are subscribed to a topic in the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ros-sig-ng-ros/coG7Wdkbb4E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ros-sig-ng-ro...@googlegroups.com.

[Ugo Cupcic]

Hi,

Just to try to get some clarification on this. Last time I spoke to Tully about a year ago about my concerns concerning ROS 2 (mainly what's been stated quite a lot: are we going to split the ROS community + migrating and maintaining two code bases for our hundreds of packages developed here is close to impossible), my feeling was that ROS2 and ROS1 would continue to live together for years to come. The general idea being to keep your existing packages in ROS1 and use ROS 2 for the use cases that really needed the new features.

Is this still the generic idea?

(Tully, sorry to drop your name in here, if I misinterpreted your comments last year, feel free to say I was wrong! :) )

Cheers,

Ugo

 

For example, how is fixing the transport layer too "intrusive" and why would it involve too much risk? I've mentioned this before, but for the transport, instead of re-writing everything, why not make a DDS-based transport layer available for all major client libraries. ROS1 could be given a DDS transport plugin (call it "DDSROS") and similar capabilities could be added to rospy and rosjava.

At the same time, OSRF can continue to develop "rclc" and the experimental "rclcpp" implementation which could be used alongside roscpp to also use this transport layer, but with a "modernized" API. Maybe instead of making this completely separate from roscpp, it could be put in the same library under the `ros::future` namespace or something along those lines. This is where support for all the new ROS infrastructure could but put and rolled in gradually. Similar functionality could be done with a `rospy.future` module.

I'll defer answering these questions to someone more knowledgeable.

Really, ROS2 as it is currently being developed is more of a ROS competitor than a second version. I'm also still curious about how Ignition Robotics fits into all of this. Is it also a ROS competitor?

Ignition Robotics is more closely related to Gazebo than ROS at the moment. Gazebo has been monolithic, with its own libraries for math, transport, etc. We have been splitting these libraries out, and they have been rebranded as Ignition Robotics libraries, in case non-Gazebo software is interested in using it but would be put off by the Gazebo name. I wouldn't name it as a ROS competitor.

I imagine the ignition-transport library is the piece that prompted the question? That library is mainly a rewrite of gazebo's custom transport layer. One difference is that the Ignition Robotics libraries can follow FHS by installing to /usr, which is a requirement for gazebo (unlike ROS, which is currently in /opt).

Steve

-j

--
You received this message because you are subscribed to a topic in the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ros-sig-ng-ros/coG7Wdkbb4E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Ugo Cupcic

Head of Software

+44 20 7700 2487

u...@shadowrobot.com

www.shadowrobot.com

---

Shadow Robot Company Ltd.
251 Liverpool Road, N1 1LX, UK
Registered Number 3308007 (England & Wales)

RoNeX - Building Robots with ROS Made Easy 

http://www.shadowrobot.com/products/ronex/

---

[Luetkebohle Ingo (CR/AEA2)]

Jon,

sometimes you need a parallel implementation to see how you could evolve the current state, because otherwise you're too biased by the effort to change some things. A clean-slate approach, if you will.

In my personal impression, which is based on digging around in it for half a year now, ROS's communication sub-system could benefit from such a clean-slate approach.

btw, I think that's separate from changing the API. You could do that while keeping the current API, which is something that is certainly dear to everybody here.

Therefore, one could ask why ROS2 is also changing API. My personal impression, again, is that reducing complexity in some aspects will require at least semantic changes.

For example, a *lot* of the complexity of the current system is caused by the "feature" that you can modify the registered callbacks while being in one. The amount of locking expended to make this possible is really quite astounding. An alternative approach, which is however not 100% semantically backwards compatible, is to hold of processing changes to the registered callbacks until after processing of the current callback is complete. I don't know which approach is currently taken in rclcpp, but it's something to look at, just to give an example of things where breaking compatibility could really reduce complexity.

cheers

Dr. Ingo Lütkebohle
Software Design and Analysis -- Robotics (CR/AEA2)

Tel. +49(711)811-12248
Fax +49(711)811-0
Mobil +49-1525-8813417
Ingo.Lue...@de.bosch.com

---

Von: ros-sig...@googlegroups.com <ros-sig...@googlegroups.com> im Auftrag von Jonathan Bohren <jonatha...@gmail.com>
Gesendet: Dienstag, 29. September 2015 20:36
An: ros-sig...@googlegroups.com
Betreff: Re: [ros-sig-ng-ros] ROS2 strategy review

 

--

[Daniel Stonier]

On 25 September 2015 at 13:59, Bill Morris <bi...@neautomation.com> wrote:

On 09/24/2015 06:06 AM, Thibault Kruse wrote:
> On Thursday, September 24, 2015 at 12:16:11 AM UTC+2, Bill Morris wrote:
>> I would also note that this seems like a bounded problem. It looks to me
>> that parallel maintenance should increase developer workload 25-110%
>> This is probably solvable by increasing the the number of active
>> developers or by moving many packages from 'development' to
>> 'maintenance' or 'inactive'
>> Being able to reuse messages should help with this.
>>
> I don't know where you see any potential for more active developers,
We can do better at training new developers. Improving documentation,
and making ROS more accessible.

Perhaps, open source development could be integrated into a industry
certification/training program. ie. each person working to become a
"Certified ROS Developer" would be expected to go through the process of
submitting pull requests to improve ROS.

Can we make opportunities for professional roboticists to contribute
more to ROS? One idea, which may be completely impractical, would be to
have a sabbatical program for engineers working in industry to work on
ROS2 at OSRF or a nearby university for a month.

Can companies sponsor a full-time staff position at OSRF?

I think this is a good idea to explore - how can we help OSRF accelerate what they do?

We couldn't make it to ROSCon this year because of parallel commitments, but we'd still like to be involved. Whilst supporting ROSCon is great as it gets people together, I'm actually more interested in helping OSRF get their development out the door into the real world whilst at the same time getting some representation/exposure for both our company and our employees.

Of course, doing what Bosch is doing would be ideal, but we're not all that well funded so we also started thinking about how we might fund development for a month or two at a time as Bill mentioned. Doing it at OSRF can be complicated though - for us finding the right person when we're a million miles away, visas, accommodation, costs of being in silicon valley, management. What we do happen to have right now though is a good computer science intern and a mentor (myself) who can facilitate doing some development for OSRF. I briefly talked to Tully about this prior to ROSCon and is something I'll pursue with him over the coming weeks. Perhaps this could be a template for future contributions?

Daniel.

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/

Yujin Inno: http://inno.yujinrobot.com/

[Brian Gerkey]

On Fri, Oct 9, 2015 at 3:11 AM, Daniel Stonier <d.st...@gmail.com> wrote:
>
>
> On 25 September 2015 at 13:59, Bill Morris <bi...@neautomation.com> wrote:
>> Can companies sponsor a full-time staff position at OSRF?
>
>
> I think this is a good idea to explore - how can we help OSRF accelerate
> what they do?
>
> We couldn't make it to ROSCon this year because of parallel commitments, but
> we'd still like to be involved. Whilst supporting ROSCon is great as it gets
> people together, I'm actually more interested in helping OSRF get their
> development out the door into the real world whilst at the same time getting
> some representation/exposure for both our company and our employees.
>
> Of course, doing what Bosch is doing would be ideal, but we're not all that
> well funded so we also started thinking about how we might fund development
> for a month or two at a time as Bill mentioned. Doing it at OSRF can be
> complicated though - for us finding the right person when we're a million
> miles away, visas, accommodation, costs of being in silicon valley,
> management. What we do happen to have right now though is a good computer
> science intern and a mentor (myself) who can facilitate doing some
> development for OSRF. I briefly talked to Tully about this prior to ROSCon
> and is something I'll pursue with him over the coming weeks. Perhaps this
> could be a template for future contributions?

Thanks for your enthusiasm!

The two key things that make our work go faster are:

(1) Contribution of your time to add features and fix bugs.
(2) Contribution of your cash to pay (more) developers at OSRF.

We're always ready to talk about both kinds of contribution.

For (1), with regards to helping with ROS 2, the best entry point is
this Waffle board (a kanban tool):
https://waffle.io/ros2/ros2
It brings together open tickets from across all the relevant
repositories. We're happy to have anybody with the time and skills to
pick up open tickets from the backlog in that board. Also, feel free
to help with code review on pending pull requests.

For (2), we work with companies in a variety of different ways. If
you're interested in discussing options for financially supporting
OSRF, just contact us directly via in...@osrfoundation.org.

[Geoff]

It's also worth pointing out the fairly detailed developer's guide:

https://github.com/ros2/ros2/wiki/Developer-Guide

There are some gaps that need to be filled in as soon as possible,
though. Things like the process that tickets go through, what is
required to move a ticket from the backlog to "ready", who can and
should be able to edit tickets (Waffle.io won't let anyone who isn't a
"collaborator" claim a ticket to work on, which defeats the purpose of
kanban), what the criteria for acceptance of a pull request (code
review) is, and so on need to be documented clearly to encourage
contributions. All this is stuff that those working together at the OSRF
take for granted, but the rest of us can't see.

Geoff

>
> For (2), we work with companies in a variety of different ways. If
> you're interested in discussing options for financially supporting
> OSRF, just contact us directly via in...@osrfoundation.org.
>

[Brian Gerkey]

On Wed, Oct 14, 2015 at 11:10 PM, Geoff <gbi...@killbots.net> wrote:
>> For (1), with regards to helping with ROS 2, the best entry point is
>> this Waffle board (a kanban tool):
>> https://waffle.io/ros2/ros2
>> It brings together open tickets from across all the relevant
>> repositories. We're happy to have anybody with the time and skills to
>> pick up open tickets from the backlog in that board. Also, feel free
>> to help with code review on pending pull requests.
>
> It's also worth pointing out the fairly detailed developer's guide:
>
> https://github.com/ros2/ros2/wiki/Developer-Guide
>
> There are some gaps that need to be filled in as soon as possible,
> though. Things like the process that tickets go through, what is
> required to move a ticket from the backlog to "ready", who can and
> should be able to edit tickets (Waffle.io won't let anyone who isn't a
> "collaborator" claim a ticket to work on, which defeats the purpose of
> kanban), what the criteria for acceptance of a pull request (code
> review) is, and so on need to be documented clearly to encourage
> contributions. All this is stuff that those working together at the OSRF
> take for granted, but the rest of us can't see.

Thanks for pointing that out. Here's a basic intro:

https://github.com/ros2/ros2/wiki/Developer-Guide#kanban-board-waffleio

I left a couple of a TODO items that my colleagues will hopefully fill in.