The Pine Formula

I should start by notifying readers that is a slightly old post, initially written in reaction to first Fairphone, then Pine64 announcing their "true wireless headphones" in April. In spite of this draft staying on my laptop since then, the situation has not particularly changed.

Some days ago, I was sitting in a dark, neon-tinted, pleasingly nerdy computing club in Berlin, with several Linux hackers around me. Most of them either had a PinePhone or a PinePhone Pro, someone else had Librem 5s plugged into their laptop as they tested out new software. Most of them were developers of mobile Linux UIs, and what we all agreed on about the ecosystem was its general immaturity, none of us feeling it was complete enough to be advertised to the general world.

In this peculiar context, it was a long discussion on how the PinePhone appeared to many as just tangently open, but not per se "ethical", that encouraged me to polish the long draft, and finally publish this post. Because, in the end, it does not say anything too new.

I joined postmarketOS chat rooms in early 2018, after strange photos of Android phones running (barely working) mainline Linux distributions grew my desire to replicate that. In all honesty, if it wasn't for the Librem 5 and PinePhone coronating my dream of seeing commercial Linux phones, I would not have started writing on this topic. But that also makes us –  or shall I say me, since I would like this post to represent my opinion exclusively – responsible for being honest. As we've been with Jingling about mainline kernels, or with FSF about a flawed certification, and with Purism about an arguably useless, "anonymous" mobile network carrier.

This article aims to represent solely my personal opinion, and reflect on an issue rather than cause further "flame wars" in the already fragmented open-source community, so take it peacefully. Discussion is always welcome, but let us keep it civil.

To start, the PinePhone became so popular because it was an amazing mobile Linux playground for its price. Similarly, the PineTab and PineBooks brought Linux laptops to pleasingly entry-level pricing, rather than pricey Intel ultrabooks. But recently, something has changed. Just in the last months, the following new Pine64 products were proposed:

• A pair of true-wireless, in-ear headphones based on an entirely proprietary SoC, an almost off-shelf design (although apparently not a clone), proprietary hardware and audio codecs from unheard silicon companies. Consumer-grade true-wireless earphones on the same chip can be found on Alibaba starting from $7.40 shipped (the BES2300 chip alone costing ~$1), the audio codec should provide acceptable sound quality. But in this way, is Pine64 trying to tackle a field as hard and closed as wireless audio through a nearly off-shelf design? (More on this later)
• Secondly, a portable audio player was annnounced, the PinePod, that would run on the same chip as the in-ear headphones.
• A third product, the PineSound, is a general development board that would expose all audio interfaces from this chip to the mercy and creativity of hobbyists and developers, possibly to experiment with wireless audio codecs and digital signal processing

But you read that right. The same chip, a closed-source, off-shelf Chinese microcontroller with 900KB RAM, will run the wireless earbuds and a portable audio player. This implies some things,

• This product family will never run Linux, as developers will need to develop a new firmware from scratch. This is obviously not a problem for the earbuds, but a big limitation for the player
• Processing wise, this chip is well sufficient for TWS headphones, but very inadequate for an audio player. It will not drive a good screen, it nor run high-resolution flacs or (probably?) support a high-quality, high-bandwidth codec. In fact, a first generation iPod Nano (retailing for $149 in 2006) had 16MB RAM, so over 16 times what the PinePod would offer. In fact, even the features of any custom firmware are limited from so little memory

In their announcement, Pine64 specified that we "will be pleased to know that the SDK has already been compiled and proven to work, and that a development board is incoming.". The base support SDK for an obscure closed chip is "compiling", and that is enough to ship a product to developers? For anyone who worked close enough to audio, this field is an absolute nightmare of codecs, licensing, closed-source libraries, and getting just the digital signal processing part of it right requires talented engineers.

I’m told that with the right tweaks, the PineBuds may actually work as over-the-counter hearing aids too. Seriously. The chipset inside the PineBuds is so versatile that it will also serve as the basis for the PinePod digital audio player. [...] Regardless, I just feel an open stand-alone music player belongs in 2022 [source]

Apart from the hearing aid claim, which  I am dubious about given the quality of microphones required for a whistle-free experience, this is no more "open" than the majority of commercial digital audio players. Both my FIIO and my XDuoo audio players are not bootloader-locked, they are flashable with custom firmware, and most of them support the "libre" Rockbox firmware that was popular in the late '00s.

In fact, considering how long the work on opening up existing players was, and how they are supported by decently well-known chip makers (Ingenic, ...), at their current stage they might be more open, while also more powerful, than a PinePod will ever be. Buy a RockBox-supported device, which often means an already open-hardware one, donate a reasonable tip to to its porting author, and you will be arguably more "ethical" than in buying a PinePod.

To be clear, I would love, and probably buy, an open-source, acceptably-high-fidelity audio player. That is something I dreamt of for years, and irrealistic sketches of some Pi Zero-based audio players are slowly decomposing somewhere in my desk drawers. But with a stack being more closed, and more underpowered, than off-shelf solutions, the PinePod does not solve any problems, but rather bets on the hope that some volunteer developer, somewhere, will reverse-engineer its chip to an usable point.

Why not just start from a decently documented SoC used in one of those off-shelf players, rather than going for a considerably more obscure one that will require an entire porting? Or why not ask users what they really want in it before, since CD-quality audio is generally easy to provide? The reason is probably cutting costs, a step too far.

This comes to the marketing pattern, the "trademark formula", that is often noticeable in Pine64's secondary products:

1. Find a successful existing product (PineTime from generic nRF52832 smartwatches, Pinecil from the open-source TS100 iron, PineNote from Remarkable). Produce a clone of it, or buy the base board design from the OEM. Then, rewrite the reference mainboard design provided by the OEM – or more often, modify it just slightly. (Again, this is nothing bad in itself - re-inventing the wheel would not make sense here)
2. Develop a product based on an anonymous, inexpensive SoC from some obscure company. All closed-source, with just minimal base-support packages (BSPs) and documentation provided.
3. Release a ton of manufacturer-supplied schematics and PDFs for closed source, obscurely inexpensive hardware present on the board as "documentation"
4. Send free early-stage samples and prototypes to a range of developers, and expect volunteers with great knowledge to work (for free, given the gifted sample devices) on it
5. Wait for them to develop a working proof-of-concept (usually alpha-level) firmware, not a beta or feature-complete one, then sell the device as an open-source community product

For some readers, this is nothing new: part of the PineNote's hardware (e.g. the e-ink panel) is not natively Linux-friendly, and the PineTime was initially criticized for looking close to a rebranded, generic Eastern smartwatch – a claim which was later debunked, although the PineTime baked a modified baseboard into the same exact closed-source chipset, plastic chassis (and possibly display?) as those.

In the past, even Rockchip, which produces chips for Pine64's "pro" line, was not famous to be open. AllWinner, which makes the A64, was very far from loved in the open-source community when the Pine64 SBC was launched. In fact, Allwinner was often vastly criticized for its GPL license violations, which were known in the linux-sunxi community (which authored most of the initial Allwinner mainline work) since the A10-based CubieBoard times. That means 2012.

Retailing from $4 to $6, the A10 and A64 ARM chips were just incredibly cheap to buy for their performance, so single-board computers competing with Raspberry Pi could be released in the $15 to $25 range, and as many developers in linux-sunxi worked hard enough on the new boards, many AllWinner chips became part of the mainline tree independently from their will.

With respect from the open source community, increasing popularity, and possibly growing sales, Pine64 has now a seal of openness on their existing devices thanks to their amazing community. But with growing prestige and respect in the Linux niche, should this not return in the form of sustainable hardware to their loyal developers and users? Why not just go for SoCs and hardware that truly respects this community, rather than exploiting them?

Most of the competition, at this point, is doing it: SHIFT, Purism, Framework, MNT Research, and Raspberry Pi are moving towards more openness, not less, as time passes. In fact, even Fairphone seems to nod at the possibility of Linux and long-term software support on their new models, although nothing official exists at the moment to confirm it.

It would be irresponsible to point out a problem without providing a solution, but thankfully, the steps here are rather intuitive. To achieve a proper "formula", which closely resembles what you will find in most other Linux device makers, Pine needs to fix up some bits:

1. Find silicon and hardware makers that care about openness

That is, without requiring a free, crowdsourced reversing of often bad and unmaintained OEM code. This should not be a problem, as there are many of them: as just one of many examples, NXP i.MX6 and i.MX8 seem a popular choice. Most open-source ARM makers including Purism, MNT Research, and most industrial embedded Linux manufacturer seem settled on this family, which is a good compromise of decent performance and acceptable pricing.

Alternatives for lower-powered SoCs – e.g. those usable in the PineBuds – that provide documentation are companies like AVR, Microchip, STM32, and the newly released RP2040. In the middle stays all the "gray area", of somewhat developer-friendly companies, which can keep prices for secondary components lower. These companies provide either a full mainline stack, or otherwise proper documentation and open code to developers, not closed-source codec "blobs".

2. Release actual software to prove the openness of boards

Rather than shipping "lazy" boards, develop a proof-of-concept, fully open-source software stack for developers to start from. That includes a panel driver, if the device has a screen, or a basic software endpoint required to use all the onboard hardware. Get the prototype of this device to work well enough the labs, to release a tiny "proof of concept"

3. Then release a developer board,

And/or an actual product based on this proof-of-concept open stack.

Otherwise, you will keep feeding the "bad apples" in the industry, that barely provide reference code for their products, and not support those who invest in making their products friendly to the end users and developers in the long run. If not even open-source hardware companies support somewhat open silicon manufacturers anymore, who will?

4. Finally, send stuff to developers

Once a basic software and hardware proof-of-concept exists, and tidy documentation has been provided to developers, it sounds fair to send devices to developers. On the PineTime and PineBuds, none of this happened, and even some early prototypes from other products were close to bricks.

As a consequence, a happier volunteer community will be thankful for the hardware and the mission behind it, and will set down develop ethical software for an ethical hardware stack in reasonable times, rather than wasting their first months of work on reversing its original, proprietary garbage stack.

In fact, being "ethical" can be a risky loophole from a financial perspective: no matter your investments, at the current stage of the tech industry, you will never be enough to define yourself so. To start, half of the production chain is messed up by a disturbing lack of human rights, and even ignoring this factor – as does essentially every manufacturer – even the greatest investments in "libre" components for a mobile device will not let you escape from hidden proprietary blobs. In fact, one of our old posts pointed out that Purism eliminated proprietary components from their software stack by hiding them exclusively in the Librem 5 modem, and updating them externally, because it is e.g. currently impossible, for legal reasons, to provide a modem with modifiable, radically open-source firmware.

As a consequence, "fairness" in technology is a spectrum, if not a multidimensional scale, with a particularly harsh curve of diminishing returns. At the current stage, there is a point at which especially smaller corporations such as Pine64 do need to take compromises. But still, the approach taken to designing a product should be detached from this market logic. If we were to see the approach to openness as a spectrum, this would have at one extreme "fully commercial off shelf hardware"  – to which the PineBuds are worryingly close – and at the other "full self made, open-hardware", which is represented e.g. by Penk's home-replicable, open-hardware projects, the Precursor, and the MNT Reform family.

The second formula will clearly cost a bit more more: "pure" hardware manufacturers need to charge a lot for hardware that, to be honest, is sometimes nowhere near "daily driver", consumer-grade quality. A Librem 5 is open, has a partly self-developed libre stack, and it is technically working, but as nothing more than a hacker concept device at its current stage. As another example, a considerably less libre Fairphone is well built for its price, but it's no iPhone.

So if being entirely "ethical", both in development and in hardware choices, is too much of a compromise for Pine to keep its prices low (or, as in recent releases, "in the lower average"), is there at least a reasonable compromise between the two? That is a question that we will leave open to Pine64 for their future decisions.

Pine64 has always been about bold product releases. Initially booming by announcing a Raspberry Pi-like single board computer for less than half the price in their early days, launching the second "modern" Linux phone when the user base did not exist, and a series of very niche mobile devices for competitive pricing in recent months, they did indeed build a loyal community over years.  But now the market is growing fast, and so is their competition.

With most alternative devices being designed to be "fair", (even more) modular, and often running mainline kernels from their nursery days (thinking of the now-hyped SHIFT6mq, which is by design a "true Linux" phone hidden in an Android hardware stack), and others being based on entirely self-designed boards for the sake of trust, Pine64 are not the only player anymore.

Now that Pine64 is growing out of the early startup phase, a direction has to be taken, and I hope that comes at an advantage of long-term technical sustainability. That is, not only in respect of their end users (which is mostly granted through open components and their FOSS software stack), but equally respectful of the time and quality of work provided by their volunteers and developers. Just my two (euro) cents.

As a second side note, after writing this I shared my draft with a mobile Linux developer, to make sure the argument was sound enough. Interestingly, their own opinion was not too far:

The Linux mobile space has changed a lot since the PinePhone released, as with most companies Pine64 are feeling the pressure of always having their new devices be better than their old ones. [...] The problem is that Pine64 have no in-house developers, and thus no way to strive towards that goal. It seems to me that they're feeling the pressure of higher expectations from their users and attempting to push it onto community developers, demanding features get fixed. Making demands like this of developers who work in their free time not for you, but for the community, is completely unacceptable. I think it's high time Pine64 consider how they reinvest into the community.

I was also recommended a post which appears to express a similar point about PINE64's "weird priorities": that is, expanding in large (e.g., gathering more distros, releasing more devices) rather than in depth and quality. I will leave a link to it below.

Pine64 should re-evaluate their community priorities