Back in June I expressed some doubts regarding viability of Luminance HDR (neé Qtpfsgui) in the review of v2.0.0. Unfortunately it looks like the doubts turn out to be true. A couple of weeks ago all project’s admins (for some reason I’m still among them) were contacted by SourceForge regarding breach of contract (selling software from SF pages is prohibited). The last official project’s maintainer never replied, the problem was resolved by previous maintainer.
Do we have to care, if Luminance HDR compiles and runs? Yes and no. Here is why.
As a photographic technology, HDR imaging has a mixed group of users: from point-and-shoot people who want their photos to look cool (mostly they want overprocessed look) to hardcore professional photographers who know what a response curve is and probably had a drink with Debevec back in 1980s.
The problem with Luminance HDR is that it doesn’t work very well for all possible groups of users. Beginners want a no-brainer UI without any of the currently existing cryptic options that are mostly undocumented and don’t even have tooltips. Advanced users want some things to get out of the way and more reliable processing (larger-than-RAM images handling is still not available).
Even with Enfuse being available there still is and will be a demand for “true” HDR. The solution as I see it is to start from scratch. The tools?
Back-end. GEGL is a clear winner. Danny Robson ported pfstools and three pfstmo tonemapping operators to GEGL this summer as part of his Google Summer of Code project. He implemented saving and loading RGBE images (.hdr) too. GEGL can also handle larger than RAM images, has code for GPU-side rendering and support for multithreading (albeit buggy at the moment).
Toolkit. I don’t care. I really don’t, as long as building installation packages for Windows and Mac users is simple and takes no more than 30 minutes of anyone’s time (because it’s boring even for contributors). I’m neither Windows nor Mac user, but they tend to be quite vocal (noisy, sometimes), so it’s best to keep them happy to spare time in the long run.
Usability. The most tricky part. In short, you can’t make everyone happy, and attempting to do so is likely to make everyone hate the result instead of loving it. In my opinion it’s best to target at advanced users, while making UI simple enough for beginners to get started with the tool. Worst thing in Luminance HDR is literal implementation of scientific papers. Nobody really needs that.
Interoperability. Apart from supporting various file formats there should be a way to submit a rendering job to the tool and get the output in managed manner (think of render farms, photo management software etc.).
Extensibility. There are all sorts of things you would want to do with an HDR image or its tonemapped version in-place. Some of the well-known tricks are merging outputs from different tonemapping operators as layers in various blending modes. Being able to reprocess one of the “layers” in the stack with different options sounds like a sensible idea to me. Or cropping in a non-destructive manner. Again, GEGL can come to aid here, so some features could be plug-in based and implemented as GEGL ops.
Such a project would need a real team of several contributors. I’m not asking for any takers, I merely “possess the greatest of all treasures which is Hope” 
But if somebody wants to work on this, I’d be glad to stick around, do some PR, docs or whatever boring non-coding work you might need to have done.