I would like to read what you think about taking a Job in companies who work extensively with ROS, but for one reason or another they are still in ROS1.
On one hand I realize that ROS is just a framework and that a lot can still be done and learned.
On the other, having worked for some years on both ROS and ROS2 I see the benefits of working with ROS2.
So I am torn and would like to hear other voices on the matter.
3 Likes
I wouldn’t read too much into it. However, about 80% of ROS users have migrated to ROS 2 and we still have six months until EOL.
I think that it demonstrates that the company isn’t really concerned with performing regular maintenance and updates. Now why that’s the case could vary for a whole host of reasons, some of them quite legitimate.
2 Likes
Perhaps they would want you to help migrate to ROS2. 
There are also some companies that are running both, due to the size and complexity of the code being migrated.
1 Like
-
By “I wouldn’t read too much into it”, you mean that it shouldn’t really hinder the company’s ability to grow (software capabilities speaking)?
-
“Isn’t concerned with regular maintnance and updates.”; I see your point, if the stack as they have it works for them then why change. What worries me beyond the updates is ease of development and compatibility with new sensors or other 3rd party elements.
Have they been around for more than a few years (back when ROS 2 wasn’t very viable for commercial applications)? Are they shipping a decent number of robots? Those would be bigger indicators than if they are still on “ROS 1”.
Realistically, in my experience, any company using ROS 1 in a production environment has probably diverged somewhat from the public ROS 1 (they have their own CI, their own mirrors of ROS Debians, maybe even their own forks of various upstream packages that they are re-packaging and re-building), so “isn’t concerned with regular maintenance and updates” might not actually apply - they are basically on a fork and self patching.
That second note of “having their own mirrors of ROS Debians” also means that the “80% of users are using ROS 2” is somewhat suspect as it is based on downloads from the public packages.ros.org repository. If you’re a corporate entity that has 500 employees and 10k robots deployed, you might only show up as a single download that occurs twice a year when your DevOps team mirrors a new set of packages and retriggers all their internal builds against it. Meanwhile, various open source packages are doing nightly builds that involve installing all of ROS 2 from public Debians into a docker image they immediately throw away… (and maybe even pulling all those Debians packages every time someone pushes to a PR…)
11 Likes
By “I wouldn’t read too much into it”, you mean that it shouldn’t really hinder the company’s ability to grow (software capabilities speaking)?
I mean exactly what I said. I wouldn’t say one or the other is more likely.
Realistically, in my experience, any company using ROS 1 in a production environment has probably diverged somewhat from the public ROS 1 (they have their own CI, their own mirrors of ROS Debians, maybe even their own forks of various upstream packages that they are re-packaging and re-building), so “isn’t concerned with regular maintenance and updates” might not actually apply - they are basically on a fork and self patching.
This is really frustrating, but I’ve seen it myself. A company can make a few fixes / changes and then not contribute that work upstream (often due to a slow or non-existent contribution guide from their legal department). This often leads to a cascade of problems for the developers. There are other reasons you would make your own infra, but this is one pattern I’ve seen. This is why it is really important that ROS users talks to their legal department about guidelines for FOSS contributions.
That second note of “having their own mirrors of ROS Debians” also means that the “80% of users are using ROS 2” is somewhat suspect as it is based on downloads from the public packages.ros.org repository. If you’re a corporate entity that has 500 employees and 10k robots deployed, you might only show up as a single download that occurs twice a year when your DevOps team mirrors a new set of packages and retriggers all their internal builds against it. Meanwhile, various open source packages are doing nightly builds that involve installing all of ROS 2 from public Debians into a docker image they immediately throw away… (and maybe even pulling all those Debians packages every time someone pushes to a PR…)
@mikeferguson I agree that download stats are sub-optimal but they are what we have. We’ve made a commitment not to include telemetry in ROS so we’re at the mercy of proxy metrics. I’ve been trying for years to get download metrics from Dockerhub to augment the data we already have, but so far that’s been unsuccessful.
On occasion I run into ROS 1 users who aren’t aware of the ROS 1 EoL (usually they are academic users). I’ve been working on little project to sus out how many remaining ROS 1 users remain are and direct them to migration help (similar to what we did with Gazebo classic). I am hoping that will land in January.
2 Likes
Why not at minimum have a simple yearly “ROS users poll”, announced to the mailing lists?
As long as you keep it VERY short (10 questions or under) I’m sure there would be high participation, and you would get a much more accurate representation than those automated things.
Sample questions:
-
VERSION used: 1, 2, or both
-
If 1, why not migrate to 2? (free form answer)
-
Approximate number of installed instances
?
2 Likes
Surveys are also a biased representation of the community, even more so than download stats. When you send out a survey your results tilt toward “people who bother to take surveys.” The mailing list in particular is a biased sample of people (i.e. people who signed up to the mailing list 5+ years ago). While imperfect, the download stats jive with what we see anecdotally (declining new Noetic packages, fewer ROSCon talk submissions, etc) so I am inclined to think they are reasonably robust.
Anyway, I don’t see how a more robust survey data is actually relevant. The results are not going to change Noetic EoL date.
4 Likes
I think the topic is already covered perfectly, but just if curious. I’ve been in a situation similar to this, and ended up resigning because of the lack of documentation of their private CI. I think as @mikeferguson pointed out, if the company is aware and really take care of things such as documentation, version control, etc. it might be interesting to dive in and get insights on a real project. The “issue” is that you won’t be “following” the public path of ROS development. In my case, I was feeling that I was reinventing the wheel and that it was a waste of time, instead of taking some time to port everything to ROS 2. Just my opinion and my personal experience, if someone finds it useful
2 Likes
With open source, you at least have the option do do it all yourself. No vendor can pull the rug from under your product. This is a major advantage of open source software.
But indeed comes at the cost of risk like developers heading off to greener pastures and increased maintenance burden. In the end, for companies, it’s an economic decision to spend time=money on porting wrt. developing new features, as with any technical debt.
@iony_m could ask if they plan to migrate in some time. If you decide to not take the job because they use EoL software, maybe it’s a sign to them as well to take this more seriously.
3 Likes
In our case, we often struggled to get PRs merged quick enough (or at all) to avoid creating a long-running fork. Once that fork exists, and changes/fixes stack up on an internal branch pending upstream PR, it becomes a real labour of love to segregate changes and upstream them. So it goes, time is short on all sides. That said, it warms me to see periodic PR merging sprees still happening in ros_comm, thanks @sloretz !
6 Likes
If it’s a ROS free-rider company and development of that application is fixed, I get the feeling that this happens quite often.
If looking for work at a company because you are motivated by ROS development, it’s a good idea to find out in advance how much the company is contributing to ROS. Also, if the company has produced a ROS 2 TSC, it will undoubtedly be actively developing ROS2.
I echo this sentiment.
We do have a fork of ROS (it’s mostly public on Github), and we do have open PRs for some large features that are “under review” since years.
However, the main reasons why we use a fork are others:
- ROS has a very strict policy saying that API/ABI can’t ever be broken within a release cycle, and this results in a large number of bug fixes to not be backported. If we notice a bug we must fix it immediately and we can’t wait more than 1 year for a new distro to come out.
- Updating ROS is very time consuming. Even if you are updating WITHIN the same distro, this means updating hundreds of packages with very little information about what and how was tested. As a company, we would have to run extensive tests for our whole pipeline. This problem is exacerbated by the fact that usually 90% of the changes are not relevant to us (i.e. we don’t need this feature/change), but nevertheless can potentially break our stuff.
For this reason we fork the whole ROS ~4-5 months after a release comes out (usually around September, when we assume the most obvious bugs have been identified) and that’s our only “sync” with the upstream.
Then we do manual cherry-picks and updates for the features/bug fixes that we care about. This greatly simplifies the testing, since we know exactly what’s being changed.
We maintain this fork until we move to a new distro, when we repeat the whole process.
2 Likes
Getting through the PR review backlog at a decent rate while also continuing to do their own development is something that all of our PMC members and committers struggle with. It can often take more time overall to review a PR properly and shepherd it to a point where it can be merged than it does to develop a feature from scratch themselves, because of the need to understand the changes fully, understand the full impact of those changes, test them to ensure they work, and write constructive comments to the submitter that help them improve the PR.
This is why I like to remind the entire community at every opportunity that anyone can review any PR. Helping out with reviewing PRs from others is the best way to increase the time available for getting your own PRs reviewed and merged, and thus reduce the time from submission to merge.
If everyone helps with reviewing PRs, then:
- there are more people doing PR reviews in total and so more time spent reviewing PRs in total, which comes around to your own PR getting reviewed faster, and
- the people who have permissions to actually merge a PR can spend less time on doing the initial reviews and more time going through PR reviews to ensure all comments have been addressed, checking the CI results, and clicking that all-important “merge” button.
3 Likes
There are some good reasons for still using ROS 1. Not many, I think, but some: mainly if you have a product that is in use by customers and needs to be supported for several more years.
However, if you are starting a new product development now, I think it is much more sensible to start it on ROS 2. This includes a new product derived from an existing product that was based on ROS 1. The reason I think this is that if you remain on ROS 1, even if its your own fork, you will have to maintain that entirely on your own from May, 2025. There will be no more upstream bug fixes to pull into your fork. On the other hand, if you shift to using ROS 2, you will benefit from the work continuing to be done by the many engineers contributing to it, which includes not just bug fixes, but also new features when you are able move up a distribution. Receiving this extra work for (mostly) free is the biggest benefit of open source software. If you then also contribute your own improvements back and help with the development of others’ contributions (such as doing PR reviews, see my above post), then everyone benefits.
I can share that among the 403 devices the Transitive agent has been installed on so far – robots and dev machines – we see the following distribution of ROS distros (some use ROS 1 and ROS 2 at the same time, some use neither):
| distro | count |
|---|---|
| kinetic | 5 |
| melodic | 4 |
| noetic | 167 |
| foxy | 21 |
| galactic | 9 |
| humble | 179 |
| iron | 4 |
| jazzy | 4 |
This data is, of course, not representative of the entire ROS user base. It is biased towards deployed robot fleets, because that’s what Transitive is most useful for, and of course our users with the largest fleets are all robotics companies, as opposed to hobbyists, students, or university labs. However, I think this is an interesting subset to consider because it sheds some light on the use of ROS 1 vs. 2 in industry.
5 Likes