Lieber Rene,
Anand Rajiva hat an verschiedenen Orten und zu verschiedenen Zeiten immer wieder sinngemäß gesagt "ich habe damit nichts mehr zu tun".
Auch mir gegenüber hat er das sehr freundlich geäußert. Daher glaube ich, dass Deinen Überlegungen, ihn einzubeziehen, insofern die Grundlage fehlt. Er will nicht, und das kann und sollte man respektieren wie ich meine (Du sicherlich auch). Kurz: Er hat so oft "nein" gesagt, dass man es einfach glauben muss. Warum auch nicht?
Das bedeutet, dass das gesamte Projekt neu gemacht werden müsste, Hardware, Software, Highlevel, Lowlevel, Treiber, einfach alles.
Weil das ein Haufen Arbeit ist, habe ich angefangen, mir über die Strukturen eines solchen Projektes Gedanken zu machen.
Übrigens: Wenn man auf "Closed Source Hardware" neue Open Source Software schreiben will, kommt man um ein wenigstens teilweises "Reverse Engineering" gar nicht herum (es wäre denn, der Entwickler hätte sich die Mühe gemacht, definierte APIs zu veröffentlichen - was hier nicht der Fall zu sein scheint). Ein solches Reverse Engineering wäre aber bereits unethisch.
Ich kann mir nicht vorstellen, wie ein gutes und dauerhaftes Projekt zu Stande kommen kann, dass mit einer solchen Handlung beginnt.
Abgesehen davon ist der Aufwand für das Reverse Engineering nicht wesentlich kleiner als der Aufwand für eine Neuentwicklung.
Darüber hinaus macht man sich abhängig von Komponenten, die vor einigen Jahren aktuell waren - wie lange sind sie aber noch lieferbar?
Die alte Hardware ist eben: Alt.
Andererseits hat Hardware auch in den letzten Jahren sehr große Fortschritte gemacht.
Zu erwähnen wäre z. B. die Ebene der Controllerchips, ohne die eine präzise UND schnelle UND leise UND langlebige UND dynamische Schrittmotorsteuerung unmöglich oder äußerst aufwendig wäre.
Weiter sind heute moderne Displays verfügbar und billig geworden; Komponenten, die USB plus Ethernet inklusive TCP/IP Stack (und ggf. Webserver) gleich mitbringen; Prozessoren, die wesentlich leistungsfähiger sind als vor wenigen Jahren und und und.
Führt man sich das vor Augen, wird schnell klar, dass jede Neuentwicklung ihrerseits in wenigen Jahren veralten wird.
Insgesamt: In meinen Augen sollte man
1) nur eine Neuentwicklung in Betracht ziehen
2) diese Neuentwicklung möglichst unabhängig von der Hardware gestalten (siehe der Hinweis auf "EFL" von Elektor)
Der letzter Punkt ist wichtig, weil so vermieden wird, dass man viel Arbeit in etwas steckt, das bald veraltet.
Hardwareunabhängige Entwicklung ist zunächst aufwendig, versetzt einen aber in die Lage, neue Hardware zeitnah und mit wenig Aufwand zu integrieren - damit kann das Projekt viel länger leben und bleibt länger aktuell.
Wie Du ganz richtig sagst, muss man dabei wohl mit einem Feature-Subset beginnen; auch, damit die Motivation der Beteiligten nicht gegen unendlich klein tendiert. Jeder will am liebsten schon bald etwas in der Hand halten.
Dennoch muss zunächst das große Ganze gedacht und dokumentiert und als gemeinsames Ziel vereinbart werden.
Denn wenn man nicht von vorne herein alle späteren Features wenigstens definiert, läuft man große Gefahr, dass die Erst-Entwicklung nicht ausreichend flexibel und erweiterbar ist und sich daher als Sackgasse erweist. Das ist dann der GAU, sozusagen.
Hat man aber zunächst das Ganze gedacht und dokumentiert, darf der Anfang auch ruhig kleiner ausfallen, weil er den Weg zum Ganzen nicht verbaut.
Soweit meine Gedanken dazu - muss nun selber arbeiten!
Herzlich, Felix