Firmware als OpenSource Projekt?

[thoschi]

Wenn ich das so lese mit dem Wachstum von Pocketbook und den damit verbundenen strukturellen Veränderungen:

Gibt es Überlegungen, die Entwicklung der Firmware in die Hände der Community zu legen (mit den PB-Entwicklern als Rückgrat und Verwalter der Closed-Source-Komponenten).

Verbunden mit einem guten Ticket-System (z.B. Redmine) und Code-Repository wäre das in meinen Augen ein spannender Gedanke.

Die sehr gute Hardware und den kundennahen Support zu verbinden mit einem offenen, direkt an die Community angebundenen Entwicklungsprozess - das wäre ein Alleinstellungsmerkmal und ich kann nur ahnen, wohin das die kränkelnde Firmware langfristig bringen könnte.

Natürlich gibts mit der Sprache, dem Wunsch, das Kind im eigenen Haus zu behalten oder der Verantwortung für die Qualitätssicherung einige Hürden - aber vielleicht wäre es ja dennoch eine interessante Perspektive...

Viele Grüße, Thomas

[cipri]

Edited

[mtravellerh]

Originally Posted by cipri

Firmware kann man eigentlich nicht so leicht open source machen, auch wenn man möchte!
Die Entwicker bekommen hardware-spezifikationen die sie geheimhalten müssen.

Wir benutzen intern schon Redmine.

[thoschi]

Originally Posted by mtravellerh

Wir benutzen intern schon Redmine.

Das spricht für Euch :-) Wir verwenden es seit ca. 3 Jahren bei meiner Arbeit.

Ich vermutete ja einige Hürden. Es wäre eben die Frage, ob man die Trennung von Hardware-und Anwendungsebene sauber trennen könnte. Wenn PB sagt, dass das unmöglich ist - dann ist es so wie es ist (ich selbst liebe meinen 903 nach erst einer Woche).

Aber ich sehe da eben eine ganze Menge Potential, wenn man sozusagen den ersten wirklichen "community based ebook-reader" hätte - selbst wenn pb federführend ist und einige Teile der Firmware nur intern betreut...

PB stellt die HW-Basis und stellt einige zentrale Funktionen solide zur Verfügung. Alternativ gibt es eine OpenSource-Firmware, in der die Nutzer ihre Wünsche realisieren können, Firmen den Reader evtl. sehr spezifisch auf Ihre Bedürfnisse anpassen, Codeschnipsel aus anderen Projekten eingehen usw...

Die Ebook-Reader-Community ist bestimmt in vielen Teilen technik-affin genug, um viele Wünsche schnell und solide umzusetzen. PB hat diesbezüglich nicht viel zu verlieren - aber gerade in diesem Markt könnte man sich zu einem wertvollen Alleinstellungsmerkmal verhelfen. Vor allem, weil es mir im Falle von PB (und im Gegensatz zu fast allen großen Mitbewerbern) die logische Fortsetzung einer engen Bindung an die Community und die bewusste Verwendung von Open Source wäre.

[cobook]

Originally Posted by cipri

Die Entwicker bekommen hardware-spezifikationen die sie geheimhalten müssen.

Welche Spezifikationen meinst du damit?

Originally Posted by thoschi

Die Ebook-Reader-Community ist bestimmt in vielen Teilen technik-affin genug, um viele Wünsche schnell und solide umzusetzen.

Und da wir eigentlich genügend Programmierer hier auch dabei haben...


Ich finde es immer wieder faszinierend und bemerkenswert, dass es im Netz so viele Open-Source-Projekte gibt, die kommerzielle Produkte durchaus um Längen schlagen...

[cipri]

Edited

[lp344]

Originally Posted by cipri

Firmware kann man eigentlich nicht so leicht open source machen, auch wenn man möchte!Die Entwicker bekommen hardware-spezifikationen die sie geheimhalten müssen

Doch, ist es eigentlich schon.
Da gibt's von den Herstellern die APIs der Bauteile, wie die anzusteuern sind. Und die APIs geheimhalten? Warum? Wie die APIs dass dann in Befehle für die Hardware umsetzen: das ja. Die Details bekommt aber auch keiner. Dafür gibt's ja die APIs, ein Abstraction Layer, der genau diese Details wegkapselt.

ILiad hat ja auch ein SDK... (http://developer.irexnet.com/iLiad/)...

Originally Posted by cipri

Die Entwicker bekommen hardware-spezifikationen die sie geheimhalten müssen.

Ich weiß nicht, wie du auf sowas kommst?

PB hat mit Sicherheit APIs für das Display, das WLan Modul, ect,ect,ect.
Also müss(t)en sie einfach über ihre eigenen Implementierungen nochmal eine Schicht drüberlegen, benötigte Schnittstellen nach außen öffnen. Und schon haben wir ein SDK ...

Originally Posted by cipri

Wie steure ich ein eInk display an, wenn ich kein ausführliches Datenblatt vom Hersteller bekomme? (Das gilt für jede andere komponente auch)
Linux hat dieses problem auch, und in manchen fällen muss man sich mit mühevoller reverse-engineering arbeit bemühen etwas "funktionierendes" und schon gar nicht optimales hinzubekommen.

Bei den Linux-Fällen ist das ein bischen anders gelagert: nämlich dann, wenn die APIs nicht auf Linux angeboten werden. DANN müssen die APIs Reverse Engineert werden. Nicht aber die Aufrufe an die API.

[cipri]

Edited

[cipri]

Edited

[cobook]

Originally Posted by cipri

Sag einaml, hast du schon schon mal eine Microkontroller programmiert? Ich schon. Und auch diverse andere Bauteile die damit in Verbindung stehen. Dazu brauchst man genau Datenblätter bis ins kleinste Detail. Man muss wissen was jedes register in detail macht.

Wir reden aneinander vorbei.

Sicher, wenn ich meine Atmels & Co. programmiere, denke ich in Strukturen wie Registern etc. Ab dem Moment, wo die Ansteuerlogik der Hardware in ICs abgekapselt ist und die Schnittstellen in der API weg sind, dann ist der Rest "normale" Programmierung von Programmen. Was einzelne Register dann machen, muss ich dann nicht mehr so genau wissen.

Im übrigen haben wir anscheinend verschiedene Definitionen, was Firmware überhaupt ist. Du zählst die Ansteuerung von Display etc. dazu... ok... Dann nimm den Ansteuerungsteil etc. mal weg, dann bleiben da immer noch Betriebssystem und Applikationen übrig, was man auch als "die" Firmware bezeichnen könnte.

Man kann ja auch die Art und Weise, wie Microprozessoren programmiert werden, nicht einfach auf Betriebssysteme oder "normale" Programme übertragen.

[MeesaYousa]

Originally Posted by cipri

Weil es eben Hersteller gibt, die Firmware nicht als open-source haben wollen (um den aufbau der Hardware besser geheimzuhalten).
Es kommt auf die Hersteller der Bauteile an, in wie fern pocketbocket code als open-source zur Verfügung stellen kann.

Tja dann entweder kein Linux verwenden, oder ordentliche Klimmzüge in der Software vollbringen um die Ansteuerung nicht im Kernel zu haben.

Ansonsten ist die Verwendung von Linux genau so nicht rechtens wie sich das Windows vom Nachbarn zu kopieren.

[devuser]

Originally Posted by MeesaYousa

Tja dann entweder kein Linux verwenden, oder ordentliche Klimmzüge in der Software vollbringen um die Ansteuerung nicht im Kernel zu haben.

Ansonsten ist die Verwendung von Linux genau so nicht rechtens wie sich das Windows vom Nachbarn zu kopieren.

Exakt!
Das ist keine Frage von "wollen" oder "nicht wollen" oder "die Firmware in die Hände der Community übergeben wollen".
Man kann keine GPL-Software nutzen und dann den Quellcode "geheimhalten", wegen NDAs mit den Hardwareherstellern. Bei Treibern ist das was anderes, aber für vorhandene GPL-lizensierte Software MUSS der Quellcode veröffentlicht werden, ob man will oder nicht. Das scheinen manche hier nicht zu verstehen.

Falls man das nicht will, darf man Linux nicht benutzen, sondern muss komplett eine eigene Firmware entwickeln, ein vorhandenes Closed-Source Firmware System lizensieren, oder ein freies System nehmen, dass keine Veröffentlichung der Quellen fordert.

Die Hersteller von DSL/WLAN-Routern verwenden häufig auch eine Firmware, die auf Linux basiert und haben es am Anfang nicht für nötig befunden, den Quellcode zu veröffentlichen. Bis sie dann einer nach dem anderen von einem Kernel-Entwickler verklagt wurden. Seitdem klappt das ganz gut mit dem Bereitstellen der Sourcen für die Firmware. Und ich kann mir die Firmware schön an meine Bedürfnisse anpassen.

Ich wollte nur der Vollständigkeit halber darauf hinweisen. Für mich persönlich ist das Thema PocketBook erledigt, da ich meinen Reader zurückgegeben habe, um mich nicht mehr über die vielen kleinen Unzulänglichkeiten der Firmware ärgern zu müssen und hilflos darauf hoffen zu müssen, dass von offizieller Stelle Abhilfe geschafft wird.

Edit:

Originally Posted by cipri

Weil es eben Hersteller gibt, die Firmware nicht als open-source haben wollen (um den aufbau der Hardware besser geheimzuhalten).
Es kommt auf die Hersteller der Bauteile an, in wie fern pocketbocket code als open-source zur Verfügung stellen kann.

Das kann man nur als Wunschdenken der Hardwarehersteller und/oder naive Sicht deinerseits bezeichnen. Die Hersteller haben gar keine Handhabe dagegen, ob jemand einen Open-Source Treiber enwickelt oder nicht. Sie können allenfalls die technischen Spezifikationen zurückhalten, um die Sache zu erschweren.
Aktuelles Beispiel? Microsoft Kinect. Eine Firma hat einen Preis für einen Open-Source Treiber ausgelobt, den sich einige Tage später jemand abgeholt hat. Seitdem kann jeder die Bewegungssteuerung jetzt auch am heimischen PC unter Linux und Windows nutzen.

[Matthias4]

Wieso soll es nicht gehen, die Firmwareentwicklung in die Hände der Community zu legen? Für meinen ersten Reader, den Hanlin V3, gibt es OpenInkpot als Open Source firmware. Das wird in einer Community entwickelt und ist wesentlich besser als die ursprünglich mitgelieferte Firmware.

[MeesaYousa]

Die Frage ist ja gar nicht ob es geht oder nicht.

Rechtlich gesehen ist PocketBook verpflichtet die Firmware für jegliche Teile die GPL Software verwendet rauszugeben.

Jedes bisschen warten wird PocketBook Kunden und loyalität kosten. Einige potentielle Entwickler hat PocketBook ja schon vergrault. Denn die die zuerst fragen sind die Entwickler die am meisten potential haben.