Even although I had worked at Espressif and I am a big fan of their microcontrollers I completely understand the frustrations and issues caused by this situation.
Suggestion: since we cannot add this external HAL to Apache, we could put it initially in GitHub.com/nuttx and slowly fixing the mainline to avoid depending on this HAL. Hopefully most of the constructions come from three Espressif contributors and all these three contributors have committer's write, so they could contribute directly to this HAL. I think this way we can get back the independente of NuttX from its tied to the vendor over the time. On Wednesday, August 5, 2026, Michal Lenc <[email protected]> wrote: > Hi, > > unfortunately Espressif HAL has the same issue as most of the company's > (not just Espressif) driven open source projects. It's open source, but you > can't really influence its direction because it's completely under > company's governance and there is no community behind it. I think it was a > mistake to let 3rd party HALs into our source code instead of providing the > support ourself - yes, the time investment would be huge and our platform > support has its own issues as well, but we sort of opened Pandora's box > with it. > > I agree our long term priority should be to get independent from all 3rd > party repositories and projects at kernel level. It's fine for the > applications, but we should have full control of drivers and supported > platforms. > > I would therefore like to ask whether it would be possible to maintain a >> fork of esp-hal-3rdparty under the Apache/NuttX umbrella, with appropriate >> NuttX committers having write access. >> > > espressif/esp-hal-3rdparty is under Apache license so I think it should be > possible to fork the repository and maintain it ourself under Apache. Not > sure if there are any restrictions on bringing forks to Apache space > though. But this would be a good middle ground between having no control > and the need to write the entire platform support from the scratch. > > Michal > > On 8/5/26 02:20, Felipe Moura Oliveira wrote: > >> Hi all, >> >> I would like to raise a concern about NuttX’s dependency on Espressif’s >> esp-hal-3rdparty <https://github.com/espressif/esp-hal-3rdparty> >> repository >> and discuss whether there is a way to give the NuttX community more >> control >> over the changes required for its development. >> >> The repository is publicly available, but it is maintained and controlled >> by a single private company. As a result, external contributions are >> handled according to that company’s internal priorities and availability, >> which can make it difficult for the NuttX community to address issues that >> block our own development. >> >> As a concrete example, I opened espressif/esp-hal-3rdparty#13 >> <https://github.com/espressif/esp-hal-3rdparty/pull/13>, it has been open >> for 28 days. It is a small change consisting of one commit and 15 added >> lines across two header files—six lines in one file and nine in the other. >> The PR has been acknowledged, but it has not received a technical review, >> and there is no expected completion date. >> >> I understand that the Espressif maintainers have other priorities, and >> this >> is not intended as criticism of the individuals involved. However, I >> believe it illustrates a governance problem for NuttX: changes required to >> support NuttX on specific hardware may depend on a repository whose review >> process and priorities are outside the control of our community. >> >> My experience while porting Dropbear <https://github.com/mkj/dropbear> >> was >> quite different. We encountered some problems during the port, but its >> maintainer actively helped by reviewing the code, suggesting changes, and >> quickly accepting the corresponding upstream pull requests. >> >> I would therefore like to ask whether it would be possible to maintain a >> fork of esp-hal-3rdparty under the Apache/NuttX umbrella, with appropriate >> NuttX committers having write access. Such a fork could continue tracking >> Espressif’s upstream repository, and generally useful changes could still >> be submitted upstream whenever possible. >> >> If maintaining a repository under Apache is not feasible or >> appropriate, another >> suggestion I have is to start building our own HAL and via kconfig select >> between the internal driver or the 3rd-party. If you have other >> suggestions, please let's talk about them. >> >> >> >> *--Felipe Moura de Oliveira* >> Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> >> >> >
