The Quiet Debt Behind Closed Forks
A big part of the robotics community relies on open-source software, especially on ROS 2 and the package ecosystem surrounding it. Robotics companies often choose to use these publicly available solutions to build their robots faster and to more swiftly reach the market, without having to always reinvent the wheel.
However, open-source robotics software isn’t a silver bullet that always lets you take a ready-made solution and deploy it directly on your robots. Most of the time, your specific use cases can uncover bugs, require changes to the underlying code, or introduce a need for completely new features in the open-source packages.
This is the point when new contributions to the open-source software are needed. However, very often, companies choose to take a different approach:
- Create a fork of an open-source repository or copy and commit the code directly to their internal code base
- Make the modifications and fixes that they need to the code that was originally open-source
- Keep using the modified version of the code, without ever committing the changes to the original public repository
This approach might appear as fast and efficient in the beginning, but what it ultimately does is that it keeps adding technical debt to your project. Forking a repository, or adding public source code directly into your code base, makes YOU the new maintainer of this code. From this point onwards, you’ll be responsible for making sure that the package is up to date with the newest changes and ensuring they are compatible with your modified code. You’ll also need to add these packages into your own testing pipelines, and the line of what is your own code vs. what is forked code slowly begins to blur. As time goes on, you’ll need to fork more and more packages and code, and soon you realize that you are actually maintaining your own custom version of ROS.
With this blog post, we want to share our experiences and insights on why we think open-source contributions are a valuable step in the success story of any robotics company, and what are the main challenges brought by taking on the effort of doing this.
The benefits of open-source contributions
Let’s start with why it is important and beneficial for companies to contribute to open-source code. And let’s clarify that we are not saying that you should open source your whole code base. No, we are only referring to the fixes, updates, and features that you make to existing open-source code, or completely new packages that can be useful for other developers and do not bring you critical business advantage.
So, instead of making bug fixes to open-source packages only in the internal fork of a repository, you should create a new pull request against the original repository to fix the issue for everyone. Or if you created a neat new package that, for example, helps you debug and analyze your DDS issues, you should definitely consider sharing it with others.
Why? For the following reasons:
- Community-driven development: Open-sourcing your code invites others, individuals and companies alike, to contribute and improve it with you. Have a feature you’ve been meaning to implement but haven’t had time for? Chances are someone else needs the same thing and might step in to help you build it.
- External code reviews: After fixing a bug locally, you’ll usually want a review. Asking a co-worker can be tricky, they have to get familiar with external code they’ve never touched before, and may not give meaningful feedback. By contributing directly to the public repo, you get reviews from maintainers who know the codebase inside out, often spotting potential issues you hadn’t even considered.
- Advancing robotics as a whole: The field of open-source robotics thrives on collaboration. Your contributions can benefit others, just as you benefit from the tools and improvements shared by the community. Progress doesn’t happen in isolation.
- Building your brand: Publishing open-source code helps both individuals and companies strengthen their brand and credibility. It shows expertise, builds trust, and can even help attract talent and customers.
- Cleaner, more maintainable code: Keeping your changes in sync with public repositories becomes much easier when you contribute upstream. Otherwise, every time you pull updates from the original repo, your internal changes risk creating merge conflicts. Avoid the hassle, upstream your fixes and keep your codebase clean and focused on what really matters.
All of these help you save money and time in the long run. However, it requires that companies actively allocate resources to develop and maintain open-source projects, which often don’t show immediate or short-term value gain.
Open-source contributions are not straightforward
From the company’s standpoint, it can sometimes be challenging to get started with open-source contributions. Convincing the company’s higher management to take such an approach can be difficult, since the value isn’t there immediately. It might be initially faster to move in the market when everything is kept in-house.
There are many practical challenges after the decision has been made to contribute to an existing open-source repository. When providing a fix to a package, you have to first of all make sure that your code changes comply with its code contribution guidelines. Finding the guidelines might not be straightforward, and it might take a few iterations of code reviews to get these things right.
Second, you might need to handle scenarios that are not directly necessary for your exact use-case. For example, if you’re fixing a bug in a navigation package that only affects wheeled robots, the maintainers might ask you to ensure that your fix doesn’t break compatibility with legged robots or drones, even if your robot doesn’t use those features. This can add extra complexity and testing work that feels unrelated to your own goals but is necessary in order to maintain the general-purpose nature of the open-source package.
And beyond that, there are many real-world friction points:
- Time investment: Contributions take time. Learning the ROS 2 contribution process, understanding licenses, writing good documentation, testing your changes across platforms, and waiting through long review cycles can delay your internal progress.
- Wider platform support: Your internal code might only need to run on Ubuntu 22.04 with ROS 2 Humble, but upstream maintainers might require it to work across Windows, RHEL or different ROS distributions. That adds effort.
- Backporting: Usually, new feature and bug fix development happens in the ROS 2 Rolling branch, which is a continuously updated development distribution. Even after your change gets accepted into Rolling, it might not be backported into older distributions like Humble. In the worst case, your team might need to wait for a full new ROS distribution cycle (years!) before the change becomes usable for you in production.
- Maintainer capacity: Some open-source packages are under-maintained. Your PR might sit unreviewed for months, and you might have to ping multiple people to get things moving.
If you are publishing a completely new package, that was, for example, originally developed only for in-house usage, you will face some further challenges:
- Removing internal dependencies: Before you can release the package, you’ll need to remove any internal company-specific utilities, logging frameworks, or build tools. Everything must be cleaned up and aligned with the standard ROS 2 way of doing things.
- Long-term support: Once the package is public, other developers might start using it. Issues will be opened, pull requests submitted, and expectations created. When the package is open-source, users expect some level of responsiveness.
- Documentation and discoverability: Releasing a package isn’t just about pushing it to GitHub. You’ll need to write a README, provide examples, and possibly release the package as a binary release to make it easily installable for the users. This adds additional packaging and release work.
All this being said, these challenges also bring a silver lining: they force you to write cleaner, modular, and more reusable code. A package that is built to be open sourced is often better designed, more loosely coupled, and more maintainable than one optimized for internal use only.
It is worth it
Contributing to open-source robotics software takes time, effort, and a shift in your mindset. It’s tempting to take the fast path: fork the repo, fix the bug, move on. But the long-term cost of maintaining your own internal forks, duplicated code-bases, and patched ROS 2 packages grows rapidly.
By contributing upstream and open sourcing reusable components, you reduce long-term maintenance burden, improve software quality, and strengthen your position in the robotics ecosystem. It’s not free, and it’s not always easy, but it pays off in the long run.
In our eyes, the benefits of open-source contributions outweigh the challenges. Many small and large companies have already chosen the path of open-source development, so we want to encourage others to do so as well!