Wie viel Aufwand, um für mehrere OS zu entwicklen?

Hi.

Ich will eine Software entwickeln, die auf jedem OS präsent sein soll. Als Jungunternehmer ist das aber eine große Hürde. Darum will ich vielleicht auch Java setzen. Aber mein Gewissen möchte es trotzdem lieber für C oder C++ sehen.

Daher würde ich gerne wissen,

1. Wie viel Aufwand das ist? Wie viel Prozent des Codes muss an das jeweilige OS angepasst werden? Wie sieht es zB bei Mozilla aus?

2. Welche Oberbegriffe es gibt, zu denen ich mich informieren kann? Hat vielleicht jemand Links oder Buchtipps?

3. Haltet ihr es für eine gute Idee, zuerst für Java zu entwickeln und dann sobald ich genug Kapital habe, noch einmal in C oder C++ anzufangen? Soll übrigens open source werden.

Was es ist, bleibt aber noch geheim. Ist aber vergleichbar mit einem Browser.

MfG

In Python:

Aufwand → 0

cooky451

Alles außer Python!

Na als erstes ist mal wichtig, möglichst alles was Systemabhängig ist zu kapseln. Heißt z.B. deine eigenen Events etc. für GUI zu erstellen, und das dann von dem jeweiligen System zu übersetzen. Nebenbei ist das eh eine gute Idee alles schön modular aufzubauen, dann kannst du Dinge schneller austauschen. Im Gegensatz zu Java hast du aber immernoch das Problem, dass die Sprache einfach keine GUI Schnittstelle bietet, heißt, du musst entweder Bibliotheken oder APIs zusätzlich lernen. Insofern würde ich sagen, ob sich das lohnt, hängt von der größe des Projekts ab. Je größer der reine Logikteil etc. ist, desdo weniger stark machen sich die Nachteile von C++ bemerkbar. Aber um mal ganz offen zu sein: Wenn du das noch nicht weißt, nimm lieber gleich Java. Nichts für ungut, aber du scheinst dir ja noch nicht mal sicher zu sein, ob du nun C oder C++ benutzen willst - und das ist nun wirklich ein Unterschied wie Himmel und Hölle. Insofern, bei der Wahl C++ willst du vielleicht erstmal ordentlich die Sprache lernen bevor du ein größeres Projekt damit angehst.

Warum kein Python? Das wäre wohl viel zu einfach gewesen oder?

Also ich würde lieber C++ wählen, wegen OOP. Allerdings ist unter Linux und Open Source C am meisten verbreitet. Darum bin ich mir noch unsicher.

Das Projekt ist ziemlich komplex. Die Semantik dahinter ist ziemlich groß. Es tendiert auch in Richtung Datenbank. Auf Dauer rentiert sich C oder C++ also garantiert.

Nur weiß ich nicht, ob ich am Anfang das alles managen und finanzieren kann. Ich bin eher ein Unternehmer, statt Programmierer. Ich habe 2 Jahre C++ Erfahrung unter Windows. Wenn der Aufwand zum Anpassen an die OS zu groß und teuer ist, dann kann ich das nicht managen und muss Java wählen. Finanzieren will ich mich durch Spenden, da es Open Source ist. Ob das Geld reicht, um plattformunabhängig zu sein?

Zeus

Ach um was für ein Projekt handelt es sich? Willst du nicht sagen, dann lass es, wie willst du spenden bekommen, wenn du nicht offen sagen kannst, um was es sich handel, obwohl es ein Open Source Projekt ist? Open Source Projekte durch Spenden ist delikat.

Hi,
C macht wirklich nur bei Systemprogrammierung Sinn. KDE wurde z. B. auch in C++ und QT programmiert, womit wir schon beim nächsten Thema Plattformunabhängigkeit sind: Du kannst C++ und QT verwenden. Die GUIs lassen sich sogar mittlerweile mit CSS erstellen, was heißt, dass da auch ein Mediengestalter ran kann, ohne auch nur eine Zeile C++ programmieren zu können.
Für QT musst du nicht mal eine Lizenz bezahlen, da dein Projekt ja OpenSource ist, aber mach dich da mal schlau welche OpenSource-Lizenz du haben musst.

Zu Python: Wenn das eine Art Datenbank sein soll, wäre Python wohl zu langsam, aber ich glaube, man kann Python sogar kompilieren. Mach dich da mal schlau...

L. G.
Steffo

Ach um was für ein Projekt handelt es sich? Willst du nicht sagen, dann lass es, wie willst du spenden bekommen, wenn du nicht offen sagen kannst, um was es sich handel, obwohl es ein Open Source Projekt ist? Open Source Projekte durch Spenden ist delikat.

Eine Art Browser oder Dateimanager. Genaueres will ich noch nicht sagen. Es dauert noch lange, bis ich das Projekt starte und will nicht, dass mir wer die Idee wegnimmt, da sie mein Einkommen sichern soll. Aber wenn ich bereit bin, kann ich das Projekt veröffentlichen ohne Angst zu haben, dass jemand anderes es besser leiten könnte.

Warum ist es delikat?

cooky451

Namenloser Held schrieb:

Aber wenn ich bereit bin, kann ich das Projekt veröffentlichen ohne Angst zu haben, dass jemand anderes es besser leiten könnte.

Und ich fürchte, dass du hier etwas naiv bist. Ich meine es ist deine Sache, aber mal angenommen du brauchst alleine 3 Monate dafür, brauchen 3 wirklich erfahren Programmierer vielleicht nur einen, um ein Produkt mit der gleichen Idee zu erstellen.

Zeus

Namenloser Held schrieb:

Warum ist es delikat?

Naja ein DocumentBrowser der so innovative ist, der die Konkurrenten
Microsoft Explorer,
Apple Finder,
Gnome Nautilus,
KDE Dolphin

dass füchten bei bringt, weil so einfach und dennoch so leistungsstark ist, dass Poweruser und Beginner es lieben wird zu nutzen. Wie willst du eine Geldgeber dazu bringen, dich mit Spenden zu versorgen? Zu Not wird's geforkt und du hast für nix gearbeitet :o

hustbaer

Herr Namenloser Held,
du willst open-sourcen, aber nicht sagen worum es genau geht?
Hmja, voll einleuchtend.

Ansonsten: Java oder C#. K.a. warum du meinst C++ sei eine tolle Idee für dein Vorhaben. Und vermutlich eher C#, weil es da GUI Toolkits gibt die nicht Scheisse sind.

cooky451

hustbaer schrieb:

Und vermutlich eher C#, weil es da GUI Toolkits gibt die nicht Scheisse sind.

Meinste des is ne gute Idee wenn man Plattformunabhängigkeit will?

hustbaer

Naja, gibt Mono.
Muss man halt aufpassen dass man nix verwendet was mit Mono nicht funktioniert. Wenn man gleich mit Mono entwickelt, oder zumindest immer parallel zum VS/Win Projekt auch ein Monodevelop Projekt pflegt (und hin und wieder auch testet) sollte es da aber keine argen Probleme geben.

Der OP schreibt ja nicht (oder ich habs überlesen?) welche Plattformen genau unterstützt werden müssen/sollen. Bzw. wie wichtig es ihm ist dass das Programm keine Installation eines Frameworks erfordert, dass es hübsch klein bleibt etc.

pumuckl

C++ hat seine Anwendungsgebiete, managed Sprachen wie Java und C# auch. Es gibt Bereiche wo man nicht klar sagen kann, welche der Sprachen im Vorteil ist, in anderen Bereichen haben native oder managed Sprachen deutliche Vorteile.

Welche Vorteile welcher Sprache bei dir überweigen kann dir wegen fehlender Infos keiner sagen. "Ich möchte so ungefähr nichts genaues will nichts verraten, kann mir jemand genau sagen was ich brauche?"

So oder so befürchte ich allerdings, dass du dir das zu einfach vorstellst. Mit zwei Jahren C++ wirds hart was größeres auf die Beine zu stellen. Dann sowas beeindruckendes hinzubekommen, dass du von Spenden aus der Open-Source Gemeinde leben kannst, wird nochmal ein paar Größenordnungen härter. Im Vergleich dazu ist es ein Klacks, Portabilität sicherzustellen.

Portablen Code zu schreiben ist nicht schwer. Du musst nur irgendwann im Laufe deines Projektes den Build-Prozess für die anderen Plattformen aufsetzen. Der Code ist kein großer Anteil. In dem Projekt, in dem ich arbeite, wird für mehrere Plattformen entwickelt. Hauptentwicklung unter Windows, andere Plattformen sind z/OS, AIX, Linux, HPUX, also auch durchaus unterschiedliche Compiler. Dazu unterschiedliche Datenbanksysteme, d.h. auf den einzelnen Plattformen haben wir zwei verschiedene Builds für die beiden DB-Systeme. Entwickelt wird in Java und C++. Der Aufwand für die Portierung auf die anderen Systeme ist jetzt, wo die Buildprozesse stehen, bei geschätzt einem Prozent.

Wie oben schon gesagt wurde ist das wichtigste, Plattformabhängigkeiten wegzukapseln. Das bedeutet, plattformunabhängige Bibliotheken zu benutzen, keine windows.h etc. einzubinden, kein C++/CLI benutzen (manche verwechseln das mit C++). Bei C++ muss dir vorher auch noch klar sein, für welche Compiler du entwickeln willst. Je nachdem wird dir TR1 und/oder C++11 zur Verfügung stehen, andere Compiler sind noch nicht so weit. Du legst damit ja auch Restriktionen für die User fest, die entsprechende Compiler haben müssen, die den Code übersetzen können. Für open source würde ich mich vielleicht sogar auf C++03 und eine Handvoll BOOST Bibliotheken beschränken.

Java ist auch nicht unproblematisch: Die wechseln ihre Subversionsnummern häufgier als andere die Unterhosen. Je nach JVM ändert sich dabei das Verhalten von einzelnen Bibliotheken ein ganz kleines Bisschen. Firefox-User sind aber gezwungen, möglichst aktuelle Java-Installationen zu benutzen, weil FF sonst das Java-Plugin abdreht. Du kannst also nicht einfach festnageln, dass du für Java Version 1.6.0.26 entwickelst sondern musst immer testen, ob dein Code auf anderen Subversionen das gleiche Verhalten hat. Bei uns in der Firma hats dafür gesorgt, dass Firefox nicht mehr zu den Referenzplattformen zählt.

Vieles zu beachten also. Der Aufwand für die Anpassung des Codes auf andere Plattform ist dazu vergleichsweise klein.

hustbaer

pumuckl schrieb:

Firefox-User sind aber gezwungen, möglichst aktuelle Java-Installationen zu benutzen, weil FF sonst das Java-Plugin abdreht. Du kannst also nicht einfach festnageln, dass du für Java Version 1.6.0.26 entwickelst sondern musst immer testen (...)

Huch?
Die Applikation kann doch ihre eigene JVM/JRE mit ausliefern, also ganz genau kontrollieren mit welcher Version sie läuft.
Zumindest unter Windows gibt es diese Option, und auf anderen Systemen sollte das doch genau so gehen, nicht?

nman

Ich nehme mal an pumuckl spricht von Applets.

muemmel

Hi,

soweit ich weis sind die neuen Embarcadero-Programmierumgebungen mit FireMonkey auch portabel. Kann Dir aber nicht sagen was der heiße Affe wirklich bringt.
Aber Du hast zumindest mit Delphi und C++ zwei sehr vernünftige Programmierumgebungen.

Gruß Mümmel

Namenloser Held schrieb:

Eine Art Browser oder Dateimanager.

Dann kannste Java oder auch zusätzliche nicht nativ laufende GUI APIs gleich vergessen, denn ich habe keine Lust, > 10 Sekunden auf den Dateimanager zu warten, bis der endlich gestartet ist.

Java Programme haben es nämlich so ansich, daß sie erstmal > 30 Sekunden zum Start brauchen, weil ja erstmal die JVM geladen werden muss.

Für nicht nativen GUI APIs, wie z.B: Qt unter Windows gilt das selbe.
Dein Qt basierter Dateimanager wäre also lediglich unter KDE schnell gestartet und unter Gnome würde es schon wieder schlecht aussehen.

Genaueres will ich noch nicht sagen. Es dauert noch lange, bis ich das Projekt starte und will nicht, dass mir wer die Idee wegnimmt, da sie mein Einkommen sichern soll.

Das was du vorhast, haben nur wenige geschafft.
Insbesondere bei reinen Endanwender Anwendungssoftware.

Schau dir als Beispiel mal den Typen von Ardour 2.0 an, der werkelt an seinem Open Source Musikprogramm und lebt von spenden.
Reicht wirst du dadurch allerdings wohl eher nicht.

Und der Typ von Cinelerra ist wohl eher an diesem Finanzierungsmodell gescheitert.
Er arbeitet zwar weiterhin an seinem Videoschnitteditor, aber die Entwicklung läuft so schleppend und bei den Features wird nur das notwendigste gemacht, während die Usability darunter leidet, daß ih fest glaube, daß er seinen Lebenunterhalt noch mit Nebenprojekten finanzieren muss.

Denn wäre dies anders, dann würde die Entwicklung bei Cinelerra anders verlaufen.

Dazu kommt dann noch, das einige dieser Entwickler einen anderen Lebensunterhalt haben und z.B. nicht in München Deutschland wohnen, sondern irgendwo anders, wo der Lebensunterhalt auch deutlich günstiger ist.
Auch dies gilt es zu beachten.

Die Spenden müßtest du dann übrigens vermutlich noch versteuern.

Fazit:
Das mit dem Open Source & Geld verdienen rechent sich meistenst nur als Dienstleistung und nicht für die Entwicklung von Endanwendersoftware, daher würde ich mir das gut überlegen.

Gegen ein Freizeitprojekt spriht allerdings nichts, wenn du Lust hast, deine Freizeit dafür zu opfern.
Ansonsten würde ich eher den klassischen Closed Source Weg wählen, der Nachteil wäre dann nur, daß dein Programm dann sicherlich nur geringe Verbreitungschancen hätte.
Denn für einen Dateimanager würde zumindest ich kein extra Geld zahlen wenn Wincows & Co bereits einen mitliefern, der meinen Anforderungen durch Gewöhnung eigentlich genügt.

Ach ja und nicht zu vergessen.

Mit Open Source sind Forks möglich.
Cinelerra-CV ist z.B. ne Abspaltung von Cinelerra und wird von der Community in der Freizeit entwickelt.
Die Usabilty von Cinelerra-CV ist daher auch besser und der Originalautor von Cinelerra hat's noch schlechter, für seine Programmierung bezahlt zu werden.

rapso

hustbaer schrieb:

pumuckl schrieb:

Firefox-User sind aber gezwungen, möglichst aktuelle Java-Installationen zu benutzen, weil FF sonst das Java-Plugin abdreht. Du kannst also nicht einfach festnageln, dass du für Java Version 1.6.0.26 entwickelst sondern musst immer testen (...)

Huch?
Die Applikation kann doch ihre eigene JVM/JRE mit ausliefern, also ganz genau kontrollieren mit welcher Version sie läuft.
Zumindest unter Windows gibt es diese Option, und auf anderen Systemen sollte das doch genau so gehen, nicht?

ja, dachte ich auch als ich fuer jemanden ein spielchen implementierte, lief auch ueberall.... bis auf bei ihm.
er hat macosx (weswegen ich erst das 'platformunabhaengige' java genommen hatte). hab dann festgestellt er hat nur 1.5, ich hatte es fuer 1.6 gebaut und auf macosx wird die version vom OS updater verwaltet. was apple drauf installiert ist sache

platformunabhaengig programmieren ist an sich nicht so der warnsinn, wenn man es von anfang an macht und weiss wie es geht (ich spreche von c++). allerdings steigt mit jeder platform natuerlich der aufwand alles zu testen, ich persoenlich versuche zwar immer linux/win/osx compatibel zu programmieren, sodass ich nur wenige dinge fixen mueste falls ich die platform wechsel, meistens erstelle und verteile ich die versionen nur fuer ein OS.

Ethon

Meine Meinung schrieb:

Ach ja und nicht zu vergessen.

Mit Open Source sind Forks möglich.
Cinelerra-CV ist z.B. ne Abspaltung von Cinelerra und wird von der Community in der Freizeit entwickelt.
Die Usabilty von Cinelerra-CV ist daher auch besser und der Originalautor von Cinelerra hat's noch schlechter, für seine Programmierung bezahlt zu werden.

Mir der richtigen Lizenz lässt sich das vermeiden.