Hello everyone, what’s the plan for after noetic? I understand that it’s the last official release, but I guess that it means that there could be community-supported releases coming up now? Is there a place to get started?
1 Like
You have approximately four years to figure it out.
If the community wants to continue support for Kinetic/Melodic/Noetic over that horizon feel free to create a new thread for it.
3 Likes
Looks at ROS 2 …
4 Likes
That’s the better answer. I gotta ask, how is supporting an EOL distro is easier than simply porting?
2 Likes
The fact that it’s known code, with known shortcomings, known limitations and known work-arounds?
Statements like these make it seem like it’s a straightforward affair to port something over to what is almost only in name a successor and ignores the fact that legacy exists.
Didn’t we recently have [Poll] Kinetic users: Kinetic EOL in April, what is your migration plan? with some surprising outcomes?
Nothing wrong with encouraging users to look at newer options, but @alainsanguinetti probably has a good reason to ask the question.
8 Likes
I think there are just as many unknowns as knowns for staying with any EOL software. The problem is that the day you really need help/support/maintenance is the first day you’ll realize it was a mistake.
3 Likes
I have to agree with Gijs. I don’t think there is anything simple about porting once you have a fleet of tens, hundreds, or thousands of robots out there. I actually feel that there is a bit of a disconnect between ROS developers and ROS practitioners. The latter are generally overwhelmed, short staffed, and constantly struggling just to keep things operational. They are also typically overloaded by change-requests of various kinds, and each change bears risk.
What people need to understand is that a robot that is accomplishing tasks 99% reliably is terrible. If you have 100 robots, each doing 100 tasks a day, then you’d be dealing with 100 issues your teams needs to debug and fix every day! That doesn’t scale and you won’t be able to keep up with that, so your customers will bear the brunt of this and won’t be happy. Since many ROS practitioners are still startups, such a disruption can turn into a real threat to the company. You really need to have a mindset of 99.9% and above, which is tough when there are changes forced on you from multiple sources every week.
On the other hand most startups are too short staffed to test for every imaginable scenario prior to pushing a release (is that space even finite?). So you generally won’t really know what will break beforehand and hence need to proceed with a lot of caution. And in that case the devil that you know is way better than “failing in new and exciting ways”, as we used to joke, while trying out the latest and greatest. And all of this doesn’t even touch on the question whether all one’s dependencies have already been ported or made compatible in some other way.
3 Likes
Sadly, I think that many if not most ROS practitioners have been following the adopt-and-fork approach for a long time already. Meaning that they will not make their business depend on an open-source ROS package without first forking it and committing the resources necessary to extend and maintain it internally. Besides the core ROS functionality and some very widely used packages like costmap2d, most people I’ve spoken with have either built their own functionality from scratch, or significantly extended and deviated from an existing package. I think the data of the recent article highlighted at ROSCon 2020 supports that view.
So while I agree with your point in general, the specifics of the kind of support people will need likely makes the question of ROS1 vs ROS2 a little less relevant than one may think, and it’s not even clear to me that people will stop learning ROS1, as your statement seems to imply.
off-topic, but this has made me very sad indeed over the years.
The only way forward is collaboration.
Why were there 20+ private forks of the nav stack (to give one example) all with many of the same fixes maintained in parallel by as many startups/companies when many of those fixes aren’t even remotely to be considered sensitive or IP?
6 Likes
I think everyone in the community should look at ROS1 to ROS2 as a continuum that takes time to make a complete transition. Start planning simple, small migrations today that are easy and over time it will make the whole migration easier. But the key is to start something today.
I think managing technical debt for open source code takes some time to find the right strategy. If you rely solely on the outside you need to keep moving or risk getting stuck. If you bring it in house, then you need to be prepared to manage that cost and potential disruptions (losing key maintainers). The beauty of ROS1 and ROS2 is that it’s meant to work together. There are strategies to evolve systems using both. You don’t have to pick just one, but it’s important to understand the risks and rewards of each and where to spend your time and money.
1 Like
Agreed. There is also the problem of private repose. I’ve been part of private repo that held fixes the public sought to have (issue in github) but couldn’t because the company didn’t want to contribute back for fear of giving an advantage to anyone else. However, the company was completely happy to continue to pay to maintain the repo internally which had no market advantage.
Here is the new thread: ROS1 Obvious Owl - let's make it happen?
I don’t respond much here, but this topic (collaboration and nav stack) are pretty close to my heart … couldn’t refrain 
off-topic, but this has made me very sad indeed over the years.
Ditto. For inspiration, when I was going through the phases of prototyping, field testing, deploying robots at a company, we very much pursued collaboration. It is extra short term effort, but it pays off when you don’t have to maintain all the things yourself.
It was and will probably always be hard to get companies to follow that line. There’s a holy trifecta that needs to be met. Engineers, leaders and timing. Engineers - it is so much easier to interact with your trusty, adorable computer than with ugly humans, even if it costs you time and effort in the long run.
Leaders - in places with pressure and tight deadlines, it generally takes that special leader to provide the inspiration and space that permits engineers to make successful collaborations (doesn’t happen too often). Once that starts though, it’s enjoyable and productive. Timing - getting two companies to sync at the same time on a large feature is hard. Most features happen just-in-time, i.e. when it’s absolutely needed. It is rare that two companies absolutely need something at the same time. That makes development - review - iteration pretty hard.
Why were there 20+ private forks of the nav stack (to give one example)
This is ironic, and perhaps a bad example. Despite my idealism at the time, this is the one example we really wanted to pursue, but ended up dropping. I had many conversations with other companies at the time attempting to create a spark for a larger collaboration, but ultimately, it just didn’t make sense.
- Nav1 stacks in products, architecturally, quickly morph into something else entirely, if not replaced
- An application’s requirements for navigation can be very different from one application to another
- Nobody is entirely that certain of what the silver bullet is, even for their own application
For me, the nav stack is one of those areas that needs to go forth and be forked, evolve in different ways for different products and then have parties come back together to design a framework. The effective collaboration today is in the smaller modules (planning, decision making engines, etc). I haven’t done much with the ros2 nav stack, but it does seem like an improvement in terms of flexibility. Nonethelss, I think it will follow a similar path. I am curious about how much input it got from companies with product experience.
4 Likes
It would be a good idea to also write about ROS2 on the wiki, so far
http://wiki.ros.org/Distributions
still does not make any mention of ROS2…
As far as I am concerned I am very well aware of ROS2, since its beta, but the fact is that ROS1 is probably going to be still here for a while. There’s nobody to blame for it and no need to look for anybody to blame 
And last but not least, telling people what to do rarely yields a lot success, so I think actually promoting ROS2 will be more efficient. For example by fixing the wiki, making ROS2 the default there on every page, polishing migration guides, gathering successful real-world project migration feedback and advertising the outstanding benefits, etc etc and hope users will follow 
1 Like
Yes, we’ve migrated away from the wiki for ROS 2 documentation. The wiki is just not sustainable long-term for several technical reasons. All of the ROS 2 documentation is over at https://docs.ros.org .
That being said, you are right that it might be a good idea to point people to ROS 2 from the ROS 1 wiki. I’ll put it on the list to consider.
7 Likes
One good way to promote ROS2 is to provide lots of free tutorials, books, and example projects.
Charles
1 Like
+1 to that. I’ve lost count of the number of times that I had to look into the forks network to find fixes, only to find them multiple times from different people.
Maybe the barrier to contribute is too high?
Of course it is. And it doesn’t help there are people like me being difficult when reviewing PRs.
One of the reasons I’ve heard the most when asking why contributions don’t seem to make it upstream (this is the polite way of saying it) is/was: “we don’t have the time to go through an iterative PR process”. That probably connects to what @Daniel_Stonier wrote (aligning companies to work on a feature).
But I do feel it’s a bit of an easy way out.
Apparently it’s more than OK to take the work of others, but not give back – that takes time and effort, which the former is in short supply and the latter better spent on developing products apparently.
2 Likes
You’re right the review process for ROS packages is thorough. But I would also say it is very welcoming and friendly, and I’ve learned a lot from the various PRs that got superb community and maintainer reviews. Most importantly - the review process often discovered hidden bugs or performance issues which would hit me later (and harder). I see submitting PRs as a real advantage compared to keeping local changes, but the question is why do others not share this view… Maybe bad experience from other communities?
1 Like
We are continuing to do reviews for PRs in moveit but are actively encouraging users to try moveit2.
As to contributing upstream, if the iterative review process is too high of a barrier to entry, I’d wonder about what internal code review process you have and the standards of quality you have internally. Surely, you wouldn’t want others contributing upstream to things you depend on without careful reviews?
As someone who’s using ROS2 recently, there are amazing features in ROS2 you probably don’t know you need until you use them. If considering what version of ROS2 to develop with I’d encourage you to use rolling and only look at LTS versions when you go to deploy.