Hi Nico, Thanks again for all the work you've done! As others have said it's much appreciated.
I hope you'll find time to stay engaged. One thing I believe is frustrating to all of us is the state of paralysis that might be (at least partially) solved with better tools and automation. For example, I'd like to prioritize getting your manibuilder patches in, and I think things like the clang-format (CB:38208) can help reduce reviewer burden as well and make it easier for newcomers to produce commit-ready patches. We can also prioritize documentation (and move it into Git?) since I think a lot of time is spent on IRC and elsewhere helping people out with the same problems over and over again.
Hard to put a name here when it feels like deciding who is to be burned out next :)
No kidding! As CDH noted it's hard and not always rewarding.
We've never really had a BDFL, and most contributions are for specific hardware that a developer is concerned with so there's not much incentive to stay on the project for a long time.
David is definitely the next most active maintainer and he knows his way around the project. If it wasn't for his support, I wouldn't have done the job in the first place. However, I fear he is as busy as any other senior developer.
Indeed, I've been mostly absent for the last few months due to time constraints. Most of my recent activity has been focused on catching up on reviews (usually small ones, but larger ones too if I have time on a weekend or something) and responding to issues reported on Github.
I definitely plan to remain involved and am happy to help move things along wherever I can, but can't make a huge time commitment.
I don't know the exact cause for the fork (maybe it was the lack of resources or the will to spend them) but I fear it might have rooted and not vanished.
I can help shed some light on this. The original cause for the fork was due to EC vendors who didn't want certain things in publicly visible code. We eventually got all that code published - it turns out there's nothing really valuable from an IP perspective as far as flashrom functionality is concerned. Eventually Chromebooks started using their own open-source EC code which eliminated the problem, but by then things had diverged quite significantly and the project was in a similar state as it is now.
There have been efforts to minimize divergence, but they always ended up in a stalemate and patches were left to bitrot on Gerrit. Nobody's fault per se, it's just how things have played out as priorities and people have changed over the years.