1 From: Boris Kraut <krt@nurfuerspam.de>
\r
2 To: undisclosed-recipients: ;
\r
3 Date: Sat, 10 May 2014 02:05:46 +0200
\r
4 Message-ID: <20140510020546.ALnhyB@whitecrest.local>
\r
5 Reply-To: Boris Kraut <krt@nurfuerspam.de>
\r
6 Subject: [.plan] Mitmach-Software
\r
8 Der aktuelle OpenSSL-Bug namens Heartbleed ist schon ziemlich beunruhigend.
\r
9 Klar, dass das einige zum Anlass genommen haben, gegen OpenSource-Software
\r
10 zu schiessen. Deren "Heilsversprechen" vom bessern Code und dem Vielaugen-
\r
11 Prinzip wuerde ja offensichtlich nicht funktionieren. OSS muesse sich mehr
\r
12 professionalisieren, kommerzieller, wirtschaftlicher und effizienter werden.
\r
14 Hier werden natuerlich viele Dinge zusamengeworfen, die keine zwingenden Ab-
\r
15 haengigkeiten sind. Amateure, die Dinge aus "Liebe" tun, sind meist sehr
\r
16 professionell -- d.h. sie sehen ihre Arbeit als Berufung an, bekennen sich
\r
17 zu ihr, sind stolz darauf. Das ist unabhaengig davon, ob oder wieviel man
\r
18 dafuer Geld bekommt oder wie hoch die resultierende Codequalitaet ist. Zudem
\r
19 muss ich hier wohl auch nicht auf den Unterschied von "offenen Quellen" und
\r
20 "freie Sofware" eingehen: Das Heilsversprechen ist die Freiheit, die Moeg-
\r
21 lichkeit selbst zu sehen, was Software tut, sie zu verstehen und sie den
\r
22 eigenen Wuenschen anzupassen. Schlechter Code wird erst dann besser, wenn
\r
23 Leute ihn lesen und verbessern. Bei FLOSS-Code kann ich das selbst tun, bei
\r
24 proprietaerer Software muss ich darauf vertrauen, dass der Hersteller das
\r
25 schon richtig gemacht hat. Wie? Der bekommt Geld dafuer? Ja und? Bitte einen
\r
26 Moment innehalten und an eine beliebige "Berufs"-Gruppe denken -- Journalisten,
\r
27 Koeche, Politiker, Anwaelte, Handwerker usw. -- und kurz ueberlegen, wann da
\r
28 das letzte mal jemand geschlampt hat, obwohl er Geld bekommen hat.
\r
30 Aber ich schweife ab, wie sooft. Wie verbessern wir FLOSS? Indem wir uns ein-
\r
31 bringen! Sicherlich, vielleicht sollte man nicht als Anfaenger -- nicht zu ver-
\r
32 wechseln mit dem Amateur (s.o.) -- gleich den Code kritischer Infrastruktur-
\r
33 projekte anfassen (anschauen, forken, fragen usw. ist aber gewuenscht!), aber
\r
34 es gibt auch so genug zu tun: Im Gegensatz zur landslaeufigen Meinung steht
\r
35 nicht hinter jeder Software ein ganzes Team, meist sind es einzelne Entwickler,
\r
36 um deren Projekt sich dann eine Schar aktiver Nutzer gebildet hat, die Fehler
\r
37 melden, Ideen einbringen, HowTos und Dokumentation schreiben oder einfach nur
\r
38 Verwaltungsaufgaben wahrnehmen. Leider haben sich seit der Computer in den All-
\r
39 tag Einzug gehalten hat die Zahlen der Entwickler, der aktiven Nutzer und der
\r
40 "passiven Anwender" nicht gleichmaessig gesteigert. Und genau hier sollte man
\r
41 einhaken: Sucht euch eine kleine Software, die ihr haeufig nutzt oder wichtig
\r
42 findet und schaut einfach mal, wer diese Software schreibt. Ein kleines Danke-
\r
43 schoen an den Entwickler? Ein Verbesserungsvorschlag? Ein paar leichte, aber
\r
44 stupide und zeitraubende Aufgaben aus dem Issuetracker erledigen? Es gibt viele
\r
47 Natuerlich sollte man immer erst vor seiner eigenen Haustuere kehren, was ich
\r
48 allerdings seit einiger Zeit mache: Auch wenn ich mich eigentlich mehr von
\r
49 Android wegentwickeln will -- das System entspricht in vielerlei Hinsicht nicht
\r
50 meiner Arbeitsweise --, bleibt mir nichts anderes uebrig, als mich weiterhin
\r
51 damit zu beschaeftigen, denn es ist ein System, das von vielen Menschen an-
\r
52 genommen wurde -- im Bildungsbereich, in Unternehmen und natuerlich im privaten
\r
53 Umfeld. Anstatt mich aber einer einzigen "App" zu verschreiben, habe ich mir
\r
54 das F-Droid-Projekt ausgesucht, ein "Market"/"AppStore"/"Repository" das nur
\r
55 freie (und meist selbstgebaute) Anwendungen bereitstellt. Natuerlich kann man
\r
56 den Server und Client auch fuer eigene (ggf. auch proprietaere) Projekte ein-
\r
57 setzen. Und damit haetten wir eigentlich die drei Teile von F-Droid:
\r
61 - Metadaten/Build-Recipes fuer freie Anwendungen
\r
63 Das ganze wird im Grossen von 2-4 Entwicklern und einigen mehr oder weniger
\r
64 aktiven Nutzern geschultert. Waehrend erstere sich hauptsaechlich auf Client
\r
65 und Server konzentrieren, waechst die Anzahl der Apps in der Warteschlange
\r
66 stetig an -- hier werden dann meist die Nutzer aktiv, so auch ich: Metadaten
\r
67 ueber FLOSS-Apps sammeln bzw. erstellen, in ein spezielles Format bringen,
\r
68 ueberlegen wie man automatisiert Updates erkennen und einspielen kann und
\r
69 natuerlich Scripte schreiben, die den ganzen Build-Prozess automatisieren.
\r
71 Sicher, das ist nicht die interessanteste Aufgabe und manche Upstream-Autoren
\r
72 sind auch etwas schwierig, wenn es darum geht Aenderungen zu machen -- also
\r
73 Mehrarbeit zu investieren --, die uns das Leben einfacher machen wuerden,
\r
74 deren Mehrwert sie aber nicht direkt sehen: Meine App kompiliert, der Code
\r
75 ist auf Github und Binaries gibt's im PlayStore... warum sollte ich bei mir
\r
76 etwas aendern, damit ihr/ein Dritter es leicht hat, ebenfalls Binaries an-
\r
77 zubieten? Zum Glueck gibt es auch immer wieder hilfsbereite und dankbare
\r
78 Menschen, die fuer den entsprechenden positiven sozialen Stimulus sorgen.
\r
80 Aber trotz aller Arbeit: Die Queue waechst staendig und auch die bereits
\r
81 vorhandenen Apps muessen regelmaessig aktualisiert und ueberprueft werden.
\r
82 Arbeits ist genug da. Bei F-Droid, wie auch bei anderen Projekten. Arbeit,
\r
83 die nur darauf wartet erledigt zu werden. Vielleicht auch von dir?
\r
86 [0] http://www.zeit.de/digital/internet/2014-04/heartbleed-openssl-open-source-heilsversprechen
\r
87 [1] https://www.gnu.org/philosophy/free-software-for-freedom.de.html
\r
88 [2] https://f-droid.org/
\r
projects / krt-msg / blob