The issue is planning, development and execution for your product lifecycle.
Just picking up an existing mature distribution release and forking components at need in your own little sandbox does not necessarily give you the end product you want, nor a sustainable long term path for your software development that suits your customer needs. Because while you were sitting there in your little bubble focusing on the needs of your embedded device for the 6-months, 1-year, 2-year it took you to get from prototype to production, the entire software stack that you initially leveraged as drastically changed and your modifications don't necessarily apply cleanly any more.
What now? Has your business model planned correctly for the cost of ongoing distribution maintenance needs like security patching beyond that initial development requirement needed to fork the mature distro?
Instead of of just basing your custom embedded work on a mature stack, how do you drive your custom work into the development of the mature stack to be a part of the ongoing maintenance of that stack and still move at the pace your business model requires?
That's the question that has really yet to be answered in the linux distribution world and that is exactly why we are seeing hardware oriented people trying to maintain weirdly constructed derivative forks of more mature distributions.
The general purpose community linux distribution model does not know how to interface with the business needs of hardware production lifecycles for device manufacturers and the device manufacturers are loath to have frank and open discussion about the problem as that discussion is tied up with business interest and what it would take to make something like Debian a better fit for their needs. It is a very difficult conversation to even start.
And to fill the gap what we are seeing are industry initiatives where peer "businesses" try to get together and align their needs and collaborate in new project structures that are perhaps vendor nuetral (for participating vendors). It's not clear how well this works in practic or what the best practices really are here. The Linux Foundation working groups are examples of this. So is Linaro, which by all accounts seems to functioning better with regard to moving ARM hardware enablement forward (primarily funded to a large extend by the ARM chip manufacturers themselves in a consortium basis I believe.)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds