Thanks for that! I pondered how to start / answer since gerbick asked "so how can we help?". Obviously first and only point I may provide right away is:

• make a list of todo items

so community knows what to search for and help with


now trying to accomplish this point and hoping for your help by e.g. adding points I missed, implementing better platform for cooperative work on editing it, add details to particular points etc:

hw production (marked "*" are items that are not blocked until completion of previous item and thus could (partially) run concurrently)

1. finish layout of proto_v2 (metacollin)
2. assemble a maybe 5 proto_v2 devices and marry them with BeagleBoard_xM (metacollin)
3. deploy proto_v2 devices to sw devels, make maemo-devuan run on them
4. create a video of a proto_v2 running maemo
5. (*) prepare and start "kickstarter" campaign to reach number_of_preorders threshold needed and to refill funds
6. * integrate BeagleBoard_xM "brainboard" (CPU, PMIC, RAM, storage, display) with proto_v2 on schematics and layout level for final design (metacollin)
7. produce and deploy a dozen proto_three release candidate devices to testers for verification (same facilities as for proto_v2, metacollin)
8. * source N900 (or "mech part" sets incl display) for the new orders from kickstarter
9. (*) source all non-standard components
10. have a factory assemble the boards
11. have another service assemble and QA-test devices ("marry" boards with case/mechparts)
12. (*) organize shipping worldwide (much more involved than it may sound)
13. set up a sustainable entity taking care about warranty and repair
14. start STEP2

adding a 2nd list which is like concurrent and complementary to the 1st one above

more generic related tasks mostly fine for community contribution

• get the already existing BeagleBoard_xM "brainboards" out to the sw devels so they can start "porting"/testing Maemo-Devuan, Debian, Gentoo, whatever you like on them. Those BB_xM differ from Neo900 only in kbd driver, display resolution and a few other minor details, they are absolutely perfect devel-boards. modem can get plugged in to USB on those, audio is a tad of a problem since it differs a bit.
• create frequent updates on website
• create/install a wikiwiki on neo900.org servers for a better community-driven todo and specs page etc
• server maintenance
• spread the word, find more supporters
• find donors/entities/programs who substantially support (or help with finding support) the project with funding and/or resources
• approach FSF to finally sort out the RYF issue and have them *officially* support the project
• Los Alamos residents visit (Meta)Collin Anderson and make sure he's well
• maybe coordinate a meeting of developers, invite interested (and interesting) new individuals to introduce the project to them
• [to be continued]

I'll frequently edit this post to add more flesh to this barebones list, until somebody comes up with a better method to do this urgently needed planning. for contributing please answer with edited fullquote so I simply can copy that fullquote over the original text - if you want to add comments not to get included in this post via editing, please use a 2nd post for them so I may delete your "edit job" posts after processing them

cheers jOERG

Comments: cannot FSF provide RYF certification for BeagleBoard_xM "brainboards"? Unlike Neo900 boards, they don't have cellular modem to argue about, correct? Or is the PowerVR graphics processor preventing RYF certification?

Thank you. Best wishes.
~~~~~~~~~~~~~~~~~
Per aspera ad astra...

quite nifty approach, should indeed work. I don't think the PowerVR is any issue since it's not needed to make the board work. FSF only reviews the SOFTWARE(!) and there exist a zillion linux versions running on BB_xM that are 100% FSF_RYF compliant. I wonder what FSF will do when we send in some device without *any* software but only schematics/docs for RYF certification. The RYF approach is too focused at rogue "product" sellers that ship a hw+sw combo, only. Evidence: no requirement for HW docs, software(!) is considered to be "the dokumentation for the hardware" - a widespread misconception among software guys.