Frustration with development pace

[kent]

the problem with PinHole (or Gnome-Camera) is that it was a last minute addition meant to address the fact that no other phone type camera apps existed. it is based on mock ups made by the GNOME team, and has a very small code base and basically no configuration. it uses libhandy which is an api that was made last minute to support gnome-camera

megapixels on the other hand is very configurable, and works using ninja. if you actually read the documentation, all of the issues that you have can be addressed by configuration (and better firmware for lower latency). take a look at the git readme:
https://git.sr.ht/~martijnbraam/megapixels

FWIW. At this point, Megapixels seems to be pretty much broken in every recent distro. Looks like it was starting to come together back in late November, but something appears to have broken the app to varying degrees across multiple platforms. So I certainly wouldn't be opposed to also having a down-and-dirty alternative that just works while everyone figures out the whiz-bang better thing.

I think the observation that started this thread is 100% accurate. In many ways the Pinephone community is running around like a chicken with it's head cut off. The obvious duplicated labor alone of different teams and individuals trying to get this one program fully working under each OS flavor is astounding. And now, whenever whatever new issue is currently breaking the program in similar ways across several distros and UIs is solved, every team will need to implement a fix in every flavor just to get each build back to where it was a month ago. If all this energy were focused on getting everything working in a single core reference OS, the project would absolutely move forward by comparative leaps and bounds.

OTOH, supporting a diversity of OS development projects is the entire point of producing this hardware platform .... so I'm not sure weather the dynamic ends up being a bug or a feature. Wanting diversity in OS selection is a double-edge sword. It probably doesn't make sense for Pine to turn around and declare a bespoke OS at this point.

My initial reaction after a couple weeks with the Pinephone ecosystem is that beyond (and adding to) the difficulties of top-level OS implementation, there have been and continue to be consistent issues with the firmware/interfaces necessary for any OS to realize full functionality of core internal hardware components. I feel this is one of the biggest limiting factors of what the larger Pinephone project can achieve. 

It isn't *really* the modem chip maker's job to provide fully baked firmware that suits the needs of every specific hardware implementation. It just isn't. Same is true for every other IC in the device. The chipmaker provides reference code. It is left to each hardware OEM to implement and optimize the provided reference code for individual use cases. The Pine team just seemingly hasn't really worked on any of the core firmware/drivers needed to support the internal device hardware. 

The current Pinephone version hit the market a bit over a year ago. The basic modem firmware is just now really coming together (and requires a manual patch process w/ a bunch of warnings and caveats). The same appears to be true for other core hardware appliances to varying degrees. That isn't to criticize Pine or anyone kicking butt making things work today, it is simply an observation of the inexorable progression of time.

We all know the Pinephone is a development platform, and I think most people purchased it without grand expectations. Personally, I am having a blast with mine. At the same time, I think almost everyone involved shares the objective of ultimately producing an end device that even a non-technical user could maintain and enjoy. Towards that objective, again, the devices are now a year older.

As technology continues to advance, the specs and capabilities of internal appliances are also advancing - along with user baseline functionality expectations. Pine has already previewed their next-gen SoC core. When that core makes it onto a phone MB, will that MB have the same modem/camera/etc. as the current phone? Or will Pine go with components that implement 5G/more capabilities/etc.? I certainly hope it's the latter, but it's a bit disheartening to realize work on the base firmware to make the next edition run won't even *begin* until that device has been mass produced and hits the hands of end developers. 

How does the software side ever possibly catch up before the hardware is obsolete?

A great phone OS is not possible if there isn't top-notch firmware running the hardware's guts. If the base isn't already rock solid, funding OS makers with no mandate to produce or improve the device's base firmware will see results limited by whatever the volunteers doing their best to improve core hardware functionality can achieve with few, if any, resources at all. 

I would love to see Pine take ownership of coordinating/maintaining the suite of Pinephone-standardized firmware needed for the hardware appliances making up the phone's internals. Similar to what others have suggested, it might be better for everyone if the percentage of sales currently being directed to top-level OS projects were instead directed to a small dedicated internal software team who could establish and maintain a relevant firmware repository. 

Pine makes logistic sense as the point to accumulate refinements in the device's internal hardware-specific code. The organization is the point of convergence for every developer working on the Pinephone hardware platform. Currently, this work is scattered in various forum posts and personal repos - with contributors often lacking a clear upstream path to provide improvements to the wider ecosystem. A common end point to consolidate improvements from the range of teams working on advancing Pinephone hardware support could move every project forward immensely. 

Additionally, staff internal to Pine would theoretically have access to the design process and prototypes to commence work on firmware for a next-gen Pinephone well before the device is mass produced and released to the community at large. Pine engineers could start working on firmware with chips on a breadboard. An external community simply can't do that - no matter how large, talented, or dedicated the community is. An investment by Pine in this area would provide a significant head start over waiting until hardware mass distribution for the work begin in earnest. 

Any way it goes, I like the Pinephone being a neutral platform and don't think Pine should try to maintain an OS. That said, in every other instance, maintaining the hardware interface stack is a hardware OEM's responsibility. The Pinephone ecosystem having a black hole in this role is certainly less than helpful.