[RFH] Future direction of the U-Boot project

[RFH] Future direction of the U-Boot project

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3110 bytes --]

Hey all,

Something I've talked about in release emails earlier this year, and
promised a follow-up on but hadn't gotten to yet, was how to manage the
project moving forward. The email I made last week about Simon also I
believe highlighted some of the problems that we as a project and
community face.

As a starting point, I want to thank all of the people (and companies)
that have been working on the project and doing the less visible but
important and expensive things that need doing. DENX has been running
much of the project infrastructure since inception. Currently, all of
the fast AMD64 build machines are from Simon. Linaro has been providing
two of the 3 fast ARM64 build machines (the other is from Simon). Our
patchwork project is on OzLabs group. A number of years ago, Simon
picked up the u-boot.org domain. There's likely other things I'm
unintentionally forgetting here.

So, what are the problems I see and would like to get some help and
guidance in working on resolving? Well, in a lot of ways it all stems
from one root cause. The project was founded on the "BDFL" model,
which was quite common at the time, and a relatively reasonable option
too.

But now? It makes getting resources harder. There are a number of people
working in the background now trying to get things donated to the
project (thank you, again) but I also know historically it's been a
challenge not having some distinct entity for U-Boot. Individual
contributions are best done as "I have a server" or similar. Conferences
are a strictly individual thing.

Then there's the day to day parts of the project. I feel like I
shouldn't complain about taking vacations where I just handle pull
requests and not patchwork stuff too, or only doing a few things on the
weekend. But it also means there's no real way to handle contentious
issues other than what I say goes. Which isn't ideal.

What to do about it? Well, I've talked with the Software Freedom
Conservancy (https://sfconservancy.org/) (SFC) earlier in the year (and
before that, years ago at conferences). There are number of open source
and community focused projects that they provide a legal entity for and
help with administrative things. I've personally been a fan of what they
do, and donated yearly for a long time. I think they would be a good fit
for the project because they do this kind of work for a number of other
big and important and community centric projects. I would encourage
anyone interested to look at their website and look around.

But that is something like step two or step three. The first step is
that I'm hoping some members of the community would like to formalize
helping with the project. SFC can help us with creating some
organizational structure for the project itself, but we need a few
people to do it. And before we even get that far, help with the mailing
list moderation queue and triaging patchwork assignments would be great.

Thanks for reading this, I look forward to finding a sustainable path
forward for the project and the community at large.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFH] Future direction of the U-Boot project

[Mattijs Korpershoek]

Hi Tom,

On Mon, Jun 02, 2025 at 16:27, Tom Rini <trini@konsulko.com> wrote:

> Hey all,
>
> Something I've talked about in release emails earlier this year, and
> promised a follow-up on but hadn't gotten to yet, was how to manage the
> project moving forward. The email I made last week about Simon also I
> believe highlighted some of the problems that we as a project and
> community face.
>
> As a starting point, I want to thank all of the people (and companies)
> that have been working on the project and doing the less visible but
> important and expensive things that need doing. DENX has been running
> much of the project infrastructure since inception. Currently, all of
> the fast AMD64 build machines are from Simon. Linaro has been providing
> two of the 3 fast ARM64 build machines (the other is from Simon). Our
> patchwork project is on OzLabs group. A number of years ago, Simon
> picked up the u-boot.org domain. There's likely other things I'm
> unintentionally forgetting here.
>
> So, what are the problems I see and would like to get some help and
> guidance in working on resolving? Well, in a lot of ways it all stems
> from one root cause. The project was founded on the "BDFL" model,
> which was quite common at the time, and a relatively reasonable option
> too.
>
> But now? It makes getting resources harder. There are a number of people
> working in the background now trying to get things donated to the
> project (thank you, again) but I also know historically it's been a
> challenge not having some distinct entity for U-Boot. Individual
> contributions are best done as "I have a server" or similar. Conferences
> are a strictly individual thing.
>
> Then there's the day to day parts of the project. I feel like I
> shouldn't complain about taking vacations where I just handle pull
> requests and not patchwork stuff too, or only doing a few things on the
> weekend. But it also means there's no real way to handle contentious
> issues other than what I say goes. Which isn't ideal.
>
> What to do about it? Well, I've talked with the Software Freedom
> Conservancy (https://sfconservancy.org/) (SFC) earlier in the year (and
> before that, years ago at conferences). There are number of open source
> and community focused projects that they provide a legal entity for and
> help with administrative things. I've personally been a fan of what they
> do, and donated yearly for a long time. I think they would be a good fit
> for the project because they do this kind of work for a number of other
> big and important and community centric projects. I would encourage
> anyone interested to look at their website and look around.
>
> But that is something like step two or step three. The first step is
> that I'm hoping some members of the community would like to formalize
> helping with the project. SFC can help us with creating some
> organizational structure for the project itself, but we need a few
> people to do it. And before we even get that far, help with the mailing
> list moderation queue and triaging patchwork assignments would be great.

I'm happy to help with the mailing list moderation queue. I'm in Europe
timezone.
I will be away for 2 months (August-Sept). Please reach out to me if you
think I can help.

>
> Thanks for reading this, I look forward to finding a sustainable path
> forward for the project and the community at large.
>
> -- 
> Tom

Re: [RFH] Future direction of the U-Boot project

[neil.armstrong]

Hi Tom,

On 03/06/2025 00:27, Tom Rini wrote:
> Hey all,
> 
> Something I've talked about in release emails earlier this year, and
> promised a follow-up on but hadn't gotten to yet, was how to manage the
> project moving forward. The email I made last week about Simon also I
> believe highlighted some of the problems that we as a project and
> community face.
> 
> As a starting point, I want to thank all of the people (and companies)
> that have been working on the project and doing the less visible but
> important and expensive things that need doing. DENX has been running
> much of the project infrastructure since inception. Currently, all of
> the fast AMD64 build machines are from Simon. Linaro has been providing
> two of the 3 fast ARM64 build machines (the other is from Simon). Our
> patchwork project is on OzLabs group. A number of years ago, Simon
> picked up the u-boot.org domain. There's likely other things I'm
> unintentionally forgetting here.
> 
> So, what are the problems I see and would like to get some help and
> guidance in working on resolving? Well, in a lot of ways it all stems
> from one root cause. The project was founded on the "BDFL" model,
> which was quite common at the time, and a relatively reasonable option
> too.
> 
> But now? It makes getting resources harder. There are a number of people
> working in the background now trying to get things donated to the
> project (thank you, again) but I also know historically it's been a
> challenge not having some distinct entity for U-Boot. Individual
> contributions are best done as "I have a server" or similar. Conferences
> are a strictly individual thing.
> 
> Then there's the day to day parts of the project. I feel like I
> shouldn't complain about taking vacations where I just handle pull
> requests and not patchwork stuff too, or only doing a few things on the
> weekend. But it also means there's no real way to handle contentious
> issues other than what I say goes. Which isn't ideal.
> 
> What to do about it? Well, I've talked with the Software Freedom
> Conservancy (https://sfconservancy.org/) (SFC) earlier in the year (and
> before that, years ago at conferences). There are number of open source
> and community focused projects that they provide a legal entity for and
> help with administrative things. I've personally been a fan of what they
> do, and donated yearly for a long time. I think they would be a good fit
> for the project because they do this kind of work for a number of other
> big and important and community centric projects. I would encourage
> anyone interested to look at their website and look around.
> 
> But that is something like step two or step three. The first step is
> that I'm hoping some members of the community would like to formalize
> helping with the project. SFC can help us with creating some
> organizational structure for the project itself, but we need a few
> people to do it. And before we even get that far, help with the mailing
> list moderation queue and triaging patchwork assignments would be great.

You can count on me for any help, for now for moderation and triage and
I'll be happy to help for the project structure.

Neil

> 
> Thanks for reading this, I look forward to finding a sustainable path
> forward for the project and the community at large.
> 

Re: [RFH] Future direction of the U-Boot project

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3614 bytes --]

On Wed, Jun 18, 2025 at 09:08:11AM +0200, Mattijs Korpershoek wrote:
> Hi Tom,
> 
> On Mon, Jun 02, 2025 at 16:27, Tom Rini <trini@konsulko.com> wrote:
> 
> > Hey all,
> >
> > Something I've talked about in release emails earlier this year, and
> > promised a follow-up on but hadn't gotten to yet, was how to manage the
> > project moving forward. The email I made last week about Simon also I
> > believe highlighted some of the problems that we as a project and
> > community face.
> >
> > As a starting point, I want to thank all of the people (and companies)
> > that have been working on the project and doing the less visible but
> > important and expensive things that need doing. DENX has been running
> > much of the project infrastructure since inception. Currently, all of
> > the fast AMD64 build machines are from Simon. Linaro has been providing
> > two of the 3 fast ARM64 build machines (the other is from Simon). Our
> > patchwork project is on OzLabs group. A number of years ago, Simon
> > picked up the u-boot.org domain. There's likely other things I'm
> > unintentionally forgetting here.
> >
> > So, what are the problems I see and would like to get some help and
> > guidance in working on resolving? Well, in a lot of ways it all stems
> > from one root cause. The project was founded on the "BDFL" model,
> > which was quite common at the time, and a relatively reasonable option
> > too.
> >
> > But now? It makes getting resources harder. There are a number of people
> > working in the background now trying to get things donated to the
> > project (thank you, again) but I also know historically it's been a
> > challenge not having some distinct entity for U-Boot. Individual
> > contributions are best done as "I have a server" or similar. Conferences
> > are a strictly individual thing.
> >
> > Then there's the day to day parts of the project. I feel like I
> > shouldn't complain about taking vacations where I just handle pull
> > requests and not patchwork stuff too, or only doing a few things on the
> > weekend. But it also means there's no real way to handle contentious
> > issues other than what I say goes. Which isn't ideal.
> >
> > What to do about it? Well, I've talked with the Software Freedom
> > Conservancy (https://sfconservancy.org/) (SFC) earlier in the year (and
> > before that, years ago at conferences). There are number of open source
> > and community focused projects that they provide a legal entity for and
> > help with administrative things. I've personally been a fan of what they
> > do, and donated yearly for a long time. I think they would be a good fit
> > for the project because they do this kind of work for a number of other
> > big and important and community centric projects. I would encourage
> > anyone interested to look at their website and look around.
> >
> > But that is something like step two or step three. The first step is
> > that I'm hoping some members of the community would like to formalize
> > helping with the project. SFC can help us with creating some
> > organizational structure for the project itself, but we need a few
> > people to do it. And before we even get that far, help with the mailing
> > list moderation queue and triaging patchwork assignments would be great.
> 
> I'm happy to help with the mailing list moderation queue. I'm in Europe
> timezone.
> I will be away for 2 months (August-Sept). Please reach out to me if you
> think I can help.

Thanks! We've talked off-list but I did want to say something in public.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFH] Future direction of the U-Boot project

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3492 bytes --]

On Wed, Jun 18, 2025 at 10:12:04AM +0200, neil.armstrong@linaro.org wrote:
> Hi Tom,
> 
> On 03/06/2025 00:27, Tom Rini wrote:
> > Hey all,
> > 
> > Something I've talked about in release emails earlier this year, and
> > promised a follow-up on but hadn't gotten to yet, was how to manage the
> > project moving forward. The email I made last week about Simon also I
> > believe highlighted some of the problems that we as a project and
> > community face.
> > 
> > As a starting point, I want to thank all of the people (and companies)
> > that have been working on the project and doing the less visible but
> > important and expensive things that need doing. DENX has been running
> > much of the project infrastructure since inception. Currently, all of
> > the fast AMD64 build machines are from Simon. Linaro has been providing
> > two of the 3 fast ARM64 build machines (the other is from Simon). Our
> > patchwork project is on OzLabs group. A number of years ago, Simon
> > picked up the u-boot.org domain. There's likely other things I'm
> > unintentionally forgetting here.
> > 
> > So, what are the problems I see and would like to get some help and
> > guidance in working on resolving? Well, in a lot of ways it all stems
> > from one root cause. The project was founded on the "BDFL" model,
> > which was quite common at the time, and a relatively reasonable option
> > too.
> > 
> > But now? It makes getting resources harder. There are a number of people
> > working in the background now trying to get things donated to the
> > project (thank you, again) but I also know historically it's been a
> > challenge not having some distinct entity for U-Boot. Individual
> > contributions are best done as "I have a server" or similar. Conferences
> > are a strictly individual thing.
> > 
> > Then there's the day to day parts of the project. I feel like I
> > shouldn't complain about taking vacations where I just handle pull
> > requests and not patchwork stuff too, or only doing a few things on the
> > weekend. But it also means there's no real way to handle contentious
> > issues other than what I say goes. Which isn't ideal.
> > 
> > What to do about it? Well, I've talked with the Software Freedom
> > Conservancy (https://sfconservancy.org/) (SFC) earlier in the year (and
> > before that, years ago at conferences). There are number of open source
> > and community focused projects that they provide a legal entity for and
> > help with administrative things. I've personally been a fan of what they
> > do, and donated yearly for a long time. I think they would be a good fit
> > for the project because they do this kind of work for a number of other
> > big and important and community centric projects. I would encourage
> > anyone interested to look at their website and look around.
> > 
> > But that is something like step two or step three. The first step is
> > that I'm hoping some members of the community would like to formalize
> > helping with the project. SFC can help us with creating some
> > organizational structure for the project itself, but we need a few
> > people to do it. And before we even get that far, help with the mailing
> > list moderation queue and triaging patchwork assignments would be great.
> 
> You can count on me for any help, for now for moderation and triage and
> I'll be happy to help for the project structure.

Thanks! Lets sync-up off list.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFH] Future direction of the U-Boot project

[Casey Connolly]

On 03/06/2025 00:27, Tom Rini wrote:
> Hey all,
> 
> Something I've talked about in release emails earlier this year, and
> promised a follow-up on but hadn't gotten to yet, was how to manage the
> project moving forward. The email I made last week about Simon also I
> believe highlighted some of the problems that we as a project and
> community face.
> 
> As a starting point, I want to thank all of the people (and companies)
> that have been working on the project and doing the less visible but
> important and expensive things that need doing. DENX has been running
> much of the project infrastructure since inception. Currently, all of
> the fast AMD64 build machines are from Simon. Linaro has been providing
> two of the 3 fast ARM64 build machines (the other is from Simon). Our
> patchwork project is on OzLabs group. A number of years ago, Simon
> picked up the u-boot.org domain. There's likely other things I'm
> unintentionally forgetting here.
> 
> So, what are the problems I see and would like to get some help and
> guidance in working on resolving? Well, in a lot of ways it all stems
> from one root cause. The project was founded on the "BDFL" model,
> which was quite common at the time, and a relatively reasonable option
> too.
> 
> But now? It makes getting resources harder. There are a number of people
> working in the background now trying to get things donated to the
> project (thank you, again) but I also know historically it's been a
> challenge not having some distinct entity for U-Boot. Individual
> contributions are best done as "I have a server" or similar. Conferences
> are a strictly individual thing.
> 
> Then there's the day to day parts of the project. I feel like I
> shouldn't complain about taking vacations where I just handle pull
> requests and not patchwork stuff too, or only doing a few things on the
> weekend. But it also means there's no real way to handle contentious
> issues other than what I say goes. Which isn't ideal.
> 
> What to do about it? Well, I've talked with the Software Freedom
> Conservancy (https://sfconservancy.org/) (SFC) earlier in the year (and
> before that, years ago at conferences). There are number of open source
> and community focused projects that they provide a legal entity for and
> help with administrative things. I've personally been a fan of what they
> do, and donated yearly for a long time. I think they would be a good fit
> for the project because they do this kind of work for a number of other
> big and important and community centric projects. I would encourage
> anyone interested to look at their website and look around.
> 
> But that is something like step two or step three. The first step is
> that I'm hoping some members of the community would like to formalize
> helping with the project. SFC can help us with creating some
> organizational structure for the project itself, but we need a few
> people to do it. And before we even get that far, help with the mailing
> list moderation queue and triaging patchwork assignments would be great.

Hi Tom,

I'd be interested in helping out too!

Kind regards,

> 
> Thanks for reading this, I look forward to finding a sustainable path
> forward for the project and the community at large.
> 

-- 
// Casey (she/her)

Re: [RFH] Future direction of the U-Boot project

[Philippe Reynes]

Hi Tom,

Le 22/07/2025 à 16:01, Casey Connolly a écrit :
> This Mail comes from Outside of SoftAtHome: Do not answer, click links or open attachments unless you recognize the sender and know the content is safe.
>
> On 03/06/2025 00:27, Tom Rini wrote:
>> Hey all,
>>
>> Something I've talked about in release emails earlier this year, and
>> promised a follow-up on but hadn't gotten to yet, was how to manage the
>> project moving forward. The email I made last week about Simon also I
>> believe highlighted some of the problems that we as a project and
>> community face.
>>
>> As a starting point, I want to thank all of the people (and companies)
>> that have been working on the project and doing the less visible but
>> important and expensive things that need doing. DENX has been running
>> much of the project infrastructure since inception. Currently, all of
>> the fast AMD64 build machines are from Simon. Linaro has been providing
>> two of the 3 fast ARM64 build machines (the other is from Simon). Our
>> patchwork project is on OzLabs group. A number of years ago, Simon
>> picked up the u-boot.org domain. There's likely other things I'm
>> unintentionally forgetting here.
>>
>> So, what are the problems I see and would like to get some help and
>> guidance in working on resolving? Well, in a lot of ways it all stems
>> from one root cause. The project was founded on the "BDFL" model,
>> which was quite common at the time, and a relatively reasonable option
>> too.
>>
>> But now? It makes getting resources harder. There are a number of people
>> working in the background now trying to get things donated to the
>> project (thank you, again) but I also know historically it's been a
>> challenge not having some distinct entity for U-Boot. Individual
>> contributions are best done as "I have a server" or similar. Conferences
>> are a strictly individual thing.
>>
>> Then there's the day to day parts of the project. I feel like I
>> shouldn't complain about taking vacations where I just handle pull
>> requests and not patchwork stuff too, or only doing a few things on the
>> weekend. But it also means there's no real way to handle contentious
>> issues other than what I say goes. Which isn't ideal.
>>
>> What to do about it? Well, I've talked with the Software Freedom
>> Conservancy (https://sfconservancy.org/) (SFC) earlier in the year (and
>> before that, years ago at conferences). There are number of open source
>> and community focused projects that they provide a legal entity for and
>> help with administrative things. I've personally been a fan of what they
>> do, and donated yearly for a long time. I think they would be a good fit
>> for the project because they do this kind of work for a number of other
>> big and important and community centric projects. I would encourage
>> anyone interested to look at their website and look around.
>>
>> But that is something like step two or step three. The first step is
>> that I'm hoping some members of the community would like to formalize
>> helping with the project. SFC can help us with creating some
>> organizational structure for the project itself, but we need a few
>> people to do it. And before we even get that far, help with the mailing
>> list moderation queue and triaging patchwork assignments would be great.
> Hi Tom,
>
> I'd be interested in helping out too!


I know  that I wake up very very late, but if you still need some help, 
I am interested in helping too.


>
> Kind regards,
>
>> Thanks for reading this, I look forward to finding a sustainable path
>> forward for the project and the community at large.
>>
> --
> // Casey (she/her)
>
Regards,

Philippe