Choices are difficult

 Free software gives us a lot of choices. But sometimes the amount of alternatives is overwhelming. Well, probably, not that much overwhelming, but even if you have, say, three options, the choice is still may be really difficult.
 I'm to develop a BSP for new computer-on-module. It means I have to add the proper board support to the kernel and pack a sufficient userspace demo that emphyzes superiority of our hardware :)
 For the kernel part I have to choose between the mainline, the CPU vendor BSP kernel, and, say, Angstrom linux-xxx recipy.
 Using the mainline kernel has the benifit if relatively easy mainlining of my own patches. On the other side, BSP kernel has way better support for the CPU features. And, finally Angstrom linux-xxx recipy allows smooth integration of my platform into the creation of entire distro.
 And the kernel to rebase on is really simple choice. The big question is what would be the userspace.
 The most simple option is to take the CPU vendor BSP "as is, without warranty, or techical support". This way I have to do almost nothing to wrap up the demo image. However, the very fist customer who'd use it will complain about lack of package X and application Y. Worse than that, the first customer who'd use such demo would fail to install or cross-compile that package X and application Y.
 Another possibility is, for instance, Debian, or even Ubuntu. You can easily install the full-featured distro in virtual machine, pack it to UBIFS adn you're done. But! It's far from being optimized, it would include things that noone will ever use, and, at least with Debian, you'll end up with very old packages.
 What's left? Of course OpenEmbedded. Here you've got exactly what you want (well, mostly), you have binaries tuned for your architecture, you do not have such crap as manuals in your images and so on, etc. Unfotrunately, using OpenEmbedded for BSP creation implies that your customer has to learn OpenEmbedded. Which is tough. It's quite possible that your customer will get stuck on building cross-toolchain because his Linux installation has only desktop and multimedia components and OpenEmbedded may depend on somthing not included in "apt-get build-essential". And, that one is really annoying, several weeks after you've branched off org.openembedded.dev you get 404 from source repository mirrors.

So, the choices are difficult...