Grundlagen der Software-Weitergabe

[kartoffel]

Tag liebe Codeäffchen ,

ich habe hier schon viel schöne Software gesehen und es gibt in diesem Forum, obwohl das nicht das Hauptthema ist, einige sehr bemerkenswerte Programmierer.
Deshalb, und weil ich selbst gelernt habe, wie schwierig so etwas sein kann, hab ich mich entschieden, diesen Guide zu schreiben, damit ihr nicht genau dieselbe, trockene Recherche-Arbeit erledigen müsst die ich hinter mir hab und euch auf das kreative Programmieren konzentrieren könnt.

Ich hab das ganze wie üblich in Spoiler eingeteilt, die verschiedene Aspekte enthalten. Wie üblich sind Verbesserungsvorschläge willkommen und werden nach möglichkeit umgesetzt. Dasselbe gilt für Ergänzungen.

		Bereitstellung über das Internet		

Niemand hat wirklich Lust, CDs zu brennen und sie an Interessenten zu verschicken, vor allem wenn die Software kostenlos oder Open-Source ist.
Also wird zur Veröffentlichung wieder mal das Internet "missbraucht", um das eigene Programm an den Mann/an die Frau zu bringen.
Dabei gibt es jedoch einige Dinge zu beachten:

				Download-Formen für Code und Binaries		
Die zu verteilende Software liegt idR. sowohl als Quellcode (wenn auch nur beim Programmierer) und als sog. Binary, also ein kompiliertes Programm (das sind .exe-Dateien für Windows-Nutzer und deren Gegenstücke bei Apfelsystemen und Pinguin-Kisten), welches in der Regel verteilt wird.

Die binären Programme sind meist diejenigen, die von den meisten Nutzern bevorzugt werden, denn nur wenige haben Spass daran, den eigenen C-Compiler lieb um ein binäres Programm zu bitten und sich dann noch mit fehlenden Libraries herumzuschlagen. Deshalb werden Binaries nach Möglichkeit als Installationspaket UND Archiv bereitgestellt. Ein großer Teil der Nutzer, zu dem auch ich gehöre, hat keinen Bock, seine Registry von jedem kleinen Tool, bzw. deren Installationsroutinen, verdrecken zu lassen. Dies gilt natürlich nicht, wenn die Routine komplizierte Aufgaben wie das Nachladen weiterer Installationsprogramme oder Dateien aus dem Netz zu tun hat.
Ansonsten: Archivdatei. Ob RAR, ZIP, 7zip oder ein komprimierter oder unkomprimierter Tarball ist dabei Jucka die Waldfee, wichtig ist nur, DASS ein Archiv da ist.

Wer jetzt auf die Idee kommt sein Eine-Datei-Programm auf eine der beiden Arten zu verteilen sollte sich ein anderes Hobby suchen.

Aber ja, der nächste Punkt ist die Codeweitergabe. Wenn das Programm unter einer Open-Source-Lizenz steht oder das Programm von einem Team entwickelt wird macht es wirklich Sinn, das ganze über SVN, Mercury oder andere Versionssysteme zu verteilen. Zur Funktionsvielfalt und den Anwendungsbereichen der Systeme konsultiert Google, Yahoo, Wikipedia, Youtube oder sonst wen außer mir. Das würde den Rahmen nämlich gewaltig sprengen.

Auch hier gilt: Wenn ihr euren Code für euch behalten wollt und auch nicht mit anderen arbeitet lasst das Verteilen einfach ganz sein. Auf eurem Rechner ist die Textsammlung ja sowieso.
	
				Webspace		
Da habt ihr eine schöne .zip-Datei, eine Installationsroutine und sonstwas fertig, aber irgendwie keinen Ort um das ganze zu veröffentlichen. Aber keine Sorge, solche Orte gibts massig:

-Freespace: Ja, Freespace. Woher auch immer. aber lest euch deren AGB und Regeln durch, es gibt viele Anbieter die Downloads strikt verbieten.

-Payspace: Selbe Regel wie oben, achtet zusätzlich auf Preis, Leistung und Support. Ich empfehle Netcup, mit denen hab ich gute Erfahrungen gemacht.

-Ein eigener Server: Okay, wenn ihr entsprechende Kenntnisse habt und ganz sicher seid, dass ihr die Leistung braucht ist das hier perfekt. Da könnt ihr Downloads mit Homepage sowie einen Versionsverwaltungs-Server parken. Sehr schick, sehr schwer einzurichten. Hier seien euch ebenfalls die vServer von Netcup ans Herz gelegt.

-Hoster für Software: Insbesondere SourceForge, die sind schon ewig da und bieten euch alles was das Herz begehrt für lau - solange ihr eure Software unter einer Open-Source-Lizenz freigebt.

-Codeverwaltungssystem-Hoster: Was ein Wort, aber wichtig ist es insbesondere bei den Lösungen die ohne Versionsverwaltung kommen. Gibt viele, für die SVN-Fans ist Google Code ganz in Ordnung. Mercury- und GIT-Fans müssen sich selbst umschauen.
	
				Dateien		
Eine einfach Liste von Dateien, die nach Möglichkeit mitgeliefert werden sollten:

-Binary des Programms: D'uh.

-Benötigte Bibliotheken: Im jeweiligen Format. In der Regel .dll- oder .so-Dateien, bzw. JARs für Java.

-README: Anweisungen für den Benutzer. Was kann das Programm, was kann es nicht, wie macht es das und was für Gefahren gibt es, ggf. auch, was nicht mitgeliefert wird. Kaffee zählt nicht.

-LICENSE: Eine Kopie des juristischen Geblubbers was manche auch als Lizenz bezeichnen. Wenn eure Software unter einer Lizenz steht hat die hier zu stehen. Nicht zu verwechseln mit der EULA.

-EULA: Keine eig. Datei, sondern eher vor der Ausführung des Programms oder während der Installation angezeigt. In der Regel nur bei den kommerzielle und bei Closed-Source-Software anzutreffen. Gilt in den meisten Ländern nur eingeschränkt, da ein Mausklick nicht zum Vertragsabschluss langt.

-INSTALL: Installationsanweisungen, in der Regel nur in Archiven, ob Binary oder Quellcode, vorhanden. Enthalten Anweisungen, wie die Software kompiliert wird und welche Bibliotheken dazu vorkompiliert werden müssen.

Wessen Software Quellcode-Patches braucht weiss was er zu tun hat. Mir gehen die Dinger auf den Senkel.
	
	

		Lizenzbedingungen		
Generell gilt für Software das Copyright. Für alle weiteren Bedingungen sind Lizenzen notwendig, die in der Datei "LICENSE" mit der Software ausgeliefert wird (siehe oben). Es gibt verschiedene Lizenzmodelle, daher gibts eine kleine Definition der wichtigsten:
				Freeware		
Freeware ist proprietär, es gibt also keine Quellcode-Freigabe, allerdings ist sie kostenlos zu haben. Es gibt keine vorgefertigten Lizenzen, die mir bekannt wären, es wird in der Regel eine EULA verwendet. Gibt noch diverse Unterarten, wie z.B. Freeware für private Nutzung, was die kommerzielle Nutzung der Freeware verbietet. Wer AntiVir verwendet weiss, wovon ich rede.
	
IM BAU!