As a software developer myself, who has made a small contribution to Darktable, I’m unpersuaded by this argument.
If a developer sees an opportunity for improvement to the DAM, they can make that change without touching the pixel pipeline, or having any impact on the ongoing work of the pipeline devs.
Also, the devs working on the pipeline are also users for the DAM. As they are experienced developers who track their code in Git, they are already accustomed to thinking about data management in terms of tags and graphs, not just folders and trees. I think most of them would agree with me that tags are a better model than folders for managing collections of photos.
AP didn’t rage quit because interface development was impeding his pipeline work. He quit over an ideological disagreement with how the project was being lead and managed that he felt was resulting in poor design choices being made and poor quality code getting merged. It just so happened that an interface change was the latest glaring example that he could point to. (That was his perspective, and that perspective is contested. I’m not trying to debate the merits of his arguments, just pointing out that his work was not directly impeded by ongoing development of the DAM interface.)
But that situation itself demonstrates that work on the DAM and it’s interface is ongoing, orthogonally to development of the pipeline.
Conversely, it would be a substantial undertaking at this point to factor out the DAM from Darktable, and make it a separate, stand-alone application. The process of doing so would be disruptive to users who like the DAM, and provide little to no benefit to the users who don’t use the DAM. The only users who would eventually benefit might be those who want to use Darktable’s DAM with a different RAW processor.
This being an open source project, if an undertaking like that was going to occur, it would more likely happen because someone who wants to use Darktable’s DAM with RT or some other processor decides to own and lead the initiative. It’s much less likely to happen because people who don’t like the DAM want want it excised from the project. As AP complained, DT’s leadership seems reluctant to throw away code if even one contributor uses it.
Speculating here: we would be more likely to see a folder-centric interface thrown into DT in addition to the existing tag-centric interface, rather than seeing the DAM split out on its own.