In part one, team members who have been involved since the early days reflected on Autoware’s development journey, while newer members shared their impressions and thoughts from before and after joining. In the second installment, the discussion focuses on the potential of open-source software (OSS).
Gakuki: Autoware isn’t something that belongs to TIER IV, its development is being steered by the Autoware Foundation (AWF). Could you share your thoughts on what you enjoy about working with open-source software?
Satoshi: Over the past year, the number of contributors to Autoware from outside TIER IV has increased significantly, making it feel much more like an OSS project. Developing autonomous driving systems often involves tasks that are recognized but not always easy to prioritize. In those moments, if we clearly outline issues – identifying things we'd like to accomplish but haven't yet – someone often steps in to offer support. Each time that happens, I’m reminded of the strengths, influence and appeal of open-source software.
Gakuki: Kenji, you often mention how happy you are to see external contributors writing documentation or fixing bugs without us even realizing it.
Kenji: Exactly! More people than I expected jump in and fix things without us even asking. It’s great to see.
Gakuki: As a member of the System Integration team who works on the user side of Autoware, what’s your perspective on this Takeshi?
Takeshi: We test robotaxis in Odaiba once every two weeks. For issues that arise during those tests, we typically analyze and resolve them ourselves. When the issue is too complex to analyze, requires specification changes, or involves the development of new features, we submit fix requests to the respective component teams. Often, when we check the Autoware repository, we come across pull requests (PRs) that look like they could resolve the issue. In many cases, those PRs do solve the problem. I think this is largely thanks to the expansion of Autoware.Universe over the past year and the increase in users and contributors.
Gakuki: It’s amazing that developers work on solutions without us even knowing. For TIER IV, which is still relatively small, that kind of contribution is incredibly valuable.
Takeshi: The number of tests we can run on our own is limited, so contributions from the open-source community are really helpful. As more people start using Autoware, It’ll be great to see the pace of improvements continue to accelerate.
Gakuki: So, are we now getting a constant flow of fixes and suggestions from people outside the AWF?
Ryohsuke: A lot of the people submitting pull requests are involved with the AWF, but recently, we’ve also seen people connecting Autoware to CARLA, an autonomous driving simulator. Some of them ended up joining working groups after coming across Autoware via CARLA. It’s clear that external contributions are on the rise. We’re also hearing from people interested in trying out Autoware. We’re hoping to bring even more contributors on board from outside TIER IV and the AWF.
Gakuki: It would be great to see more contributions from individual users, not just those affiliated with companies.
Ryohsuke: Definitely. For people in research labs or students, I think it’s a resource that is easy to use.
Gakuki: When it comes to handling queries, it's common to see direct communications on Autoware's GitHub Discussions. I’ve noticed that the developers who implemented the features often respond directly, which highlights how close the relationship is between users and developers.
Yoshi: I think being close to the users is really great. I've worked in research and development at universities and companies, but there were few opportunities to receive direct feedback from users. There were times when I would wonder how meaningful a project was. In that sense, knowing that so many people use Autoware gives you a real sense of purpose when creating commits. It’s also rewarding to get feedback on the features I’ve worked on and to be able to help solve problems. The close connection with users is what makes it so enjoyable.
Kento: These days, I don’t commit code as much myself, but I frequently provide feedback during PR reviews. I’ll suggest improvements like optimizing code for speed or removing unnecessary parts to streamline the process. One of the interesting things about open-source software is the sense of responsibility it brings. People take ownership of the code they review as if it were their own – you can't overlook bugs. That’s how people contribute to the software's development.
Gakuki: Have any challenges emerged due to the increasing number of contributors?
Ryohsuke: Since it’s not our own software, there needs to be consensus within the community when making changes or adding features. The process starts with a discussion on GitHub, and when everyone’s on board, we outline the big picture. Once we have a rough idea, we seek feedback from the committee, and after agreeing on the approach, we create an issue and assign it to the person or team responsible.
Reviewers are usually people with expertise in the area or the owner of the original code. Although there was always a general flow, the process has recently been formalized to make it easier for everyone to contribute. Reaching consensus still takes time, so in that sense, it's more challenging than developing internally. But working with a diverse group of developers and organizations has also made certain aspects of development easier. Looking at the big picture, I’d say it's more efficient than keeping everything within TIER IV. Things are moving in the right direction.
Gakuki: What are your thoughts on the challenges and areas that need to be addressed in open-source development?
Ryohsuke: Just because it’s open source doesn’t mean everyone will use it. If the software isn’t genuinely good, the community won’t grow. People will likely lose interest and move on if TIER IV starts focusing on self-serving goals. That’s why it’s important to continuously add new features and ensure we’re creating something truly valuable, while remembering that it’s a collective effort. Pressure comes from the need to demonstrate that we’re delivering something worthwhile.
While enhancing features, it’s important to ensure that we can guarantee safety. That calls for clear specifications, such as the expected performance under specific conditions. This is one of the key challenges. We can't place all the responsibility on the reviewers, either. Another challenge lies in improving the CI/CD framework and building a system that can support a variety of user needs.
Gakuki: How are you approaching the challenge of supporting a wide range of use cases within an OSS ecosystem?
Maxime: We’re tackling this by working with AWF members to define the ODDs we aim to support. Our approach is the same for any ODD: when an issue arises, we discuss it with both internal and external members to find a solution, then repeat the process. Since the people involved have such diverse backgrounds, the issues and challenges we encounter can vary as well. For example, issues can arise from the size of the vehicle.
We were previously focused on cargo transport, but recently we’ve started working on a shuttle bus ODD. With buses, challenges related to vehicle size have emerged, particularly in the Planning/Control areas. There are discussions within the AWF regarding this. Sometimes, we propose solutions to problems brought up by others, and other times, we raise issues that TIER IV is struggling to resolve. Each of us brings problems to the table, takes them back for consideration, and then we discuss them again. This cycle continues as we move forward with development.
Gakuki: Working with such a diverse group means gaining a lot of different perspectives, but I imagine it comes with its own challenges too.
Ryohsuke: At the architecture level, there were times when opinions diverged. With everyone coming from different backgrounds, we had to hold several discussions to find a compromise, and sometimes one side would have to give in to reach a solution. Through these experiences, we arrived at the idea of defining a minimal set of interfaces in Autoware Core/Universe while giving people the freedom to design their own architectures. At the same time, while TIER IV follows a specific architecture, we wanted to ensure that if someone proposes a different approach, the architecture can be updated. As long as it can be reverted, anything goes, which has made things much easier.
Kenji: There are many use cases for autonomous driving, and there’s a lot we can’t know until we try, so architecture design is really challenging. But that’s also what makes it rewarding.
Maxime: When it comes to challenges, there are still times when collaboration between different components isn't sufficient. Since I'm responsible for Planning/Control, I would like to increase collaboration with the Perception and Localization teams. Without such collaboration, discussions about functional design tend to lack perspectives from other fields. For example, those designing the Planning side often focus on ensuring that the obstacle detection timing [timestamp] is accurate, while the Perception team designs with the actual recognition performance in mind. To some extent, this is a common challenge in both internal and external development activities. I would like to have more open discussions to incorporate the way of thinking of the people in charge of other components.
Gakuki: I’d also like to ask about the challenges in using the system. In open-source software, there are times during releases when things change. Does this become a burden when developing and evaluating products? from the perspective of the Planning/Control Team, how do you feel about this Satoshi?
Satoshi: Since Autoware is being developed so quickly, it’s hard to keep track of all the changes in real-time, and there are many instances where things change unexpectedly. In such circumstances, releasing the software can often be quite challenging. That's why I think it's important to minimize bugs as much as possible on a daily basis, and this is where the spotlight falls on CI/CD improvements, as Ryohsuke mentioned. Since anyone can now participate in the development, we want to put more effort into maintaining the functionality and make evaluations during releases a bit easier.
Ryohsuke: Regarding CI/CD, for the localization feature, we haven't been able to create test scenarios yet due to the need for sensor data, but we do have a plan in place to address this.
Yoshi: In Sensing/Perception, we currently use data from past real-world driving incidents to conduct qualitative evaluations, but we would like to make it more quantitative. Also, it would be better if we could evaluate not just the recognition part, but also the integration with the subsequent Planning/Control stages.
Don’t miss the third and final part of this roundtable, where the participants describe the type of people who would thrive at TIER IV.
TIER IV is always on the lookout for passionate individuals to join our journey. If you share our vision of making autonomous driving accessible to all, get in touch.
Visit our careers page to view all job openings.
If you’re uncertain about which roles align best with your experience, or if the current job openings don’t quite match your preferences, register your interest here. We’ll get in touch if a role that matches your experience becomes available, and schedule an informal interview.
Media contact
pr@tier4.jp
Business inquiries
sales@tier4.jp
Social Media
X (Japan/Global) | LinkedIn | Facebook | Instagram | YouTube
More