Vendors providing their own forks of open source projects as SDKs is a stupid, wasteful way of supporting SBCs. We can do better.
I do not disagree with this, although I personally still don't know how to leverage open-source in a healthy business model.
With Linux SBCs, we can assume profits come from the hardware sales, so the target (for the vendor) should be to minimize maintenance cost while maximizing the user demand. Forking a kernel and/or a distribution maximizes maintenance cost (since you'll be doing it all yourself), with the only vendor benefit being that the vendor can hopefully force users to upgrade to another SBC when the support ends. Problem is, those users won't have any incentive to pick that vendor again, especially if the vendor uses a shorter product cycle than the users prefer (which is always, because users want BOTH the old stuff maintained forever AND the new stuff also).
An appliance baseboard vendor could push the component support upstream, and generate documentation on how to do the systems integration properly, achieving vanilla kernel and typical userspace support from the get go. The inertia there is the proprietary give-us-the-SDK model you need to overturn first; it can be a bit of a fight to get the Cxx bigwigs to understand that this is better than the old proprietary way.
SoC vendors like Samsung and Amlogic are already doing this; similarly for the RISC-V support itself (by RISC-V foundation and companies like SiFive).
What is still lacking is the documentation on how to do it properly and efficiently without wasting money, I guess.
I might sound like a zealot, but that's a misunderstanding. For example, I do not mind that appliance providers have their own userspace applications and services and daemons that are proprietary, as long as they use the same kernel APIs as everything else. As a systems integrator myself –– I like to put together my own "distros" for dedicated devices and appliances –– binary kernel blobs mean that I cannot reliably debug the kernel; vendor kernel trees mean I have to backport any later changes from vanilla kernels to the vendor tree (unless the tree is so mangled, like on many Asus routers, that it is impossible to do); and so on. Basically, binary blobs and vendor trees tie my hands in a way that makes it less than worth the necessary effort for me.
It annoys me more, because I do firmly believe that getting the support upstreamed is, for the vendor, for the entire product lifetime,
cheaper than having someone maintain the forks and packaging. You may have to hire an actual professional instead of random highschoolers, though. Smaller overall cost-benefit ratio, in other words.
For hobbyists who just use the SBCs according to guides and videos, having binary OS images one can use from the get go is more important, sure.
But is an SBC targeting only the hobbyists and rejecting the integrators and open source developers actually
viable? RPI does it, but the foundation pays quite a few people to do the integration and maintenance stuff for them; actual profit-seeking companies without SoC vendor patrons with deep pockets are hard-pressed to duplicate that. The Pi "clone" manufacturers seem to thrive by pushing a new model out at least once a year –– except for the ones who do push the support upstream.
If a fully working system is achievable with packages only from the Debian repositories (no vendor-specific packages or software needed), basically all my worries and objections here are voided.(And if that happens, I want one of these, too. Especially if it can boot of M.2 SSD without an initrd on an SD-card or USB memory stick.)
What I
fear is what I have seen many times before, and the "Debian" support is actually a Debian
fork provided by the vendor; a specific version snapshot, that the vendor "promises" to maintain for a short while, with kernel sources "coming soon" (and when available, cannot reproduce the distributed binaries). Debian itself will grow and fix bugs, but those won't affect the vendor fork, unless actively backported by the vendor.
Maybe not an issue for pure end users, I dunno, but definitely an issue for integrators and system/appliance developers like myself.
So, why am I whining here, bothering a thread about crowd funded projects? Because this project is already so close, but at high risk of making the same old fatal flaws as other SBC projects have done before. I'm hoping that if people point it out, the flaws could be avoided. Perhaps not for this kickstarter, but by the next model; I'd be happy with that, too. If this feels like I'm slighting the Kickstarter project or anyone else, I apologize; not my intent.
Home
Help
Search
Login
Register
