Jeder kann an Open-Source Projekten mitwirken. Dass hierfür nicht unbedingt Spezial- oder Programmierkenntnisse notwendig sind, bespreche ich in der aktuellen Folge.
Transkript
Das Transkript wurde maschinell erstellt und kann Fehler enthalten. Es zählt
das gesprochene Wort.
Ausklappen
00:00–0:00:11
Herzlich willkommen zu einer neuen Folge Bildungsfern, die Sommerferien haben begonnen und jetzt hat
0:00:11–0:00:18
man endlich mal Zeit, Dinge zu tun, die richtig Spaß machen und zu denen man sonst nicht
0:00:18–0:00:19
so kommt.
0:00:19–0:00:24
Ja, da kann man sich überlegen, was könnte man dann jetzt machen, wenn der Urlaub ja
0:00:24–0:00:30
sowieso vielleicht ein wenig kürzer ausfällt oder sogar ganz in die Tonne fällt.
0:00:30–0:00:33
Vielleicht kann man sich mal irgendwo bei einem Open Source Projekt engagieren.
0:00:33–0:00:39
Da gibt es eine ganze Menge Möglichkeiten und insbesondere für alle, die jetzt sagen,
0:00:39–0:00:45
ich kann aber nicht programmieren, es gibt auch andere Möglichkeiten der Mitwirkung und
0:00:45–0:00:50
jeder, der sich engagieren möchte in ganz unterschiedlichen Bereichen, ist da herzlich
0:00:50–0:00:51
willkommen.
0:00:51–0:00:55
Und da kann man sich mal so ein bisschen vorstellen, wie man sich engagieren kann.
0:00:55–0:01:03
Ja, da gibt es eine Veranstaltung, die normalerweise immer erst im Oktober stattfindet, das sogenannte
0:01:03–0:01:04
Hektoberfest.
0:01:04–0:01:11
Das ist eine Veranstaltung, die von GitHub zusammen mit Digital Ocean durchgeführt wird
0:01:11–0:01:17
und wo es darum geht, nochmal einen Blick auf Open Source Projekte zu lenken und insbesondere
0:01:17–0:01:23
auch den Einstieg in die Entwicklung von Open Source ein wenig zu erleichtern.
0:01:23–0:01:30
Die Idee dahinter ist, dass man auf zum Beispiel GitHub, das ist eine Plattform für Softwareentwicklung,
0:01:30–0:01:36
nachguckt, was gibt es denn für unterschiedliche Projekte und was gibt es für Möglichkeiten,
0:01:36–0:01:38
sich bei den Projekten zu engagieren.
0:01:38–0:01:42
Das Offensichtliche ist natürlich, wenn eine Software einen Fehler hat, dass man diese Fehler
0:01:43–0:01:48
Häufig werden die Fehler dann in sogenannten Issue-Trackern oder Bug-Trackern gesammelt
0:01:48–0:01:51
und dann kann man gucken, ok, was gibt es denn hier für Probleme.
0:01:51–0:01:57
Meist ist es allerdings auch schon so, wenn sie leicht zu lösen wären, dann hätte man
0:01:57–0:01:58
sie schon gelöst.
0:01:58–0:02:03
Deswegen ist es meist ein bisschen komplizierter und nicht so gut geeignet für Einsteiger.
0:02:03–0:02:08
Es gibt aber noch eine ganze Menge anderer Dinge zu tun rund um ein Open Source Projekt.
0:02:08–0:02:14
Das kann zum Beispiel sein, dass eine Dokumentation überarbeitet werden muss oder erstmal geschrieben
0:02:14–0:02:15
werden muss.
0:02:15–0:02:19
Das kann man auch machen, ohne dass man Software-Programmierung kann.
0:02:19–0:02:25
Ein weiterer Aspekt ist Übersetzungen, wenn es zum Beispiel eine Dokumentation schon in
0:02:25–0:02:30
Englisch gibt, aber noch nicht in meiner Zielsprache oder die Anwendung selbst, wenn
0:02:30–0:02:34
die eine Oberfläche hat, die in unterschiedlichen Sprachen zur Verfügung gestellt wird.
0:02:34–0:02:38
Vielleicht ist es da auch nochmal interessant zu schauen, was gibt es da für Möglichkeiten,
0:02:38–0:02:41
sich selber nochmal einzubringen, gerade wenn man vielleicht ein bisschen esoterische Sprachen
0:02:41–0:02:46
spricht, also nicht Englisch und Französisch oder Spanisch, dann gibt es da sicherlich
0:02:46–0:02:50
viele Möglichkeiten an ganz vielen unterschiedlichen Stellen sich einzubringen.
0:02:50–0:02:56
Ich werde dazu auch nochmal einen Link in die Shownotes oder die Webseite packen, wo
0:02:56–0:03:06
es eine Möglichkeit gibt, über eine Webseite auf unterschiedliche solche Issues zu stoßen.
0:03:06–0:03:14
Da gibt es nämlich erstmal einen Blogartikel von GitHub selbst, die das auch für sich
0:03:14–0:03:21
entdeckt haben und dann mit Hilfe von künstlicher Intelligenz und Lernalgorithmen geguckt haben,
0:03:21–0:03:26
was wären eventuell solche Issues, die man da angehen könnte.
0:03:26–0:03:35
Es gibt aber auch Seiten wie issuehub.io oder gauga.io, die schon mal geguckt haben, was
0:03:35–0:03:42
wären denn sinnvolle Issues, um für einen Steiger dort einen Ansatz zu bekommen.
0:03:42–0:03:48
An einem Issue kann man nämlich ein Label dranhängen und damit das so ein bisschen kategorisieren.
0:03:48–0:03:55
Und da hat sich ein Label wie zum Beispiel Trivial oder Good First Issue etabliert und
0:03:55–0:04:00
wenn man danach ein bisschen sucht, findet man auch Themen, die für einen selber gut
0:04:00–0:04:01
geeignet sind.
0:04:01–0:04:04
Wie läuft das dann im Allgemeinen ab?
0:04:04–0:04:10
Also wir haben so etwas wie GitHub, das ist eine Oberfläche oder ein Portal mit ganz vielen
0:04:10–0:04:16
unterschiedlichen Projekten und jedes Projekt hat eine Quelltextverwaltung und da ist dann
0:04:16–0:04:20
zum Beispiel auch die Dokumentation drin, Bilder sind da drin, alles mögliche, was
0:04:20–0:04:23
zu dem Projekt gehört, findet sich an dieser Stelle.
0:04:23–0:04:30
Und wenn ich jetzt einen Beitrag leisten möchte, dann mache ich das nicht direkt in dieser
0:04:30–0:04:36
Projektinfrastruktur, man nennt das dann Repository, ich trage da also nicht etwas direkt in das
0:04:36–0:04:42
Repository ein, weil ja, eventuell ist das nicht korrekt oder die Chefentwickler hätten
0:04:42–0:04:47
da gerne noch die eine oder andere Anpassung, sondern ich mache da erstmal eine Kopie von
0:04:47–0:04:53
dieser gesamten Infrastruktur, also von diesem Repository und man nennt das dann einen Fork.
0:04:53–0:04:58
Ich forke also das Repository und habe dann meine eigene Version, mit der ich dann arbeiten
0:04:59–0:05:05
In diesem Fork kann ich dann beliebig herumarbeiten, verschiedene Änderungen durchführen und dann
0:05:05–0:05:11
habe ich natürlich einen Unterschied zu dem Original Repository und GitHub hilft einem
0:05:11–0:05:16
dann dabei, diese Unterschiede darzustellen und dann kann ich sagen, ich habe hier folgende
0:05:16–0:05:20
Änderungen durchgeführt, zum Beispiel an diesen und diesen Dateien, ich habe hier vielleicht
0:05:20–0:05:26
noch ein neues Logo hinzugefügt und die kann ich dann als Änderungen vorschlagen.
0:05:26–0:05:35
Bei GitHub nennt sich das Pull-Request, Pull, also man bittet die andere Seite, die eigenen
0:05:35–0:05:41
Änderungen hier hinüber zu ziehen in das Projekt und daher der Name, die Entwickler
0:05:41–0:05:45
gucken sich das an, eventuell gibt es da noch den einen oder anderen Hinweis, vielleicht
0:05:45–0:05:49
hat man da auch etwas falsch gemacht, was eigentlich gar keine Verbesserung, sondern
0:05:49–0:05:54
eher eine Verschlechterung ist, das ist also Ziel dieses Pull-Requestes und der Diskussion
0:05:54–0:05:57
um diesen Pull-Request, genau das auszuschließen und zu verhindern.
0:05:57–0:06:06
Wenn alles gut geklappt hat, dann hat man ein neues Feature hinzugefügt oder die Dokumentation
0:06:06–0:06:12
überarbeitet und hat dann einen kleinen Beitrag geleistet und wenn man erstmal damit angefangen
0:06:12–0:06:18
hat, diese Beiträge zu leisten, entwickelt sich vielleicht dann auch noch Interesse
0:06:18–0:06:24
und Freude daran, das weiter vorzuführen, vielleicht in dem selben Projekt, vielleicht
0:06:24–0:06:29
aber auch in einem ganz anderen Projekt und man schaut dann, wo man da noch weiter mitarbeiten
0:06:30–0:06:36
Kurz zusammengefasst, wenn du eine Idee hast, wenn dich Dinge interessieren und du möchtest
0:06:36–0:06:41
gerne bei der Open-Source-Entwicklung etwas beisteuern, schau einfach mal bei issuehub.io
0:06:41–0:06:48
nach, guck, welche Issues sind dort als "good first issue" markiert und guck, wo kann ich
0:06:48–0:06:49
da weiterhelfen?
0:06:49–0:06:56
Eine andere Strategie ist es, es gibt vielleicht ein Projekt, was du super spannend findest,
0:06:56–0:07:01
dann schau mal, ob du die Quelltexte und die Möglichkeiten mitzuwirken irgendwo auf der
0:07:01–0:07:07
Projektseite findest, das könnte bei github sein oder auch bei anderen Plattformen, github
0:07:07–0:07:11
ist jetzt eine recht große und prominente, aber sicherlich nicht die einzige und schau
0:07:11–0:07:15
dann, ob du das Projekt dann irgendwie unterstützen kannst, indem du es direkt raussuchst.
0:07:15–0:07:22
Eine andere Möglichkeit ist es, zumindest bietet github das an, die Projekte nach sogenannten
0:07:22–0:07:27
Themengebieten oder Topics sich anzuschauen, also interessiert mich jetzt Webentwicklung
0:07:27–0:07:35
oder Spiele oder Systemtools, habe ich Interesse für bestimmte Programmiersprachen, dann kann
0:07:35–0:07:41
man da noch mal ein bisschen genauer das zusammenschauen und dann einfach mal reinschauen, ob man da
0:07:41–0:07:42
sich beteiligen kann.
0:07:42–0:07:50
Probier es einfach mal aus, vielleicht kannst du damit dann auch etwas wieder zurückgeben.
0:07:50–0:07:54
Ich meine, wir nutzen alle Open Source in ganz vielen unterschiedlichen Fällen, entweder
0:07:54–0:08:00
bewusst oder unbewusst, viele Open Source Projekte finden wir in eingebetteten Systemen
0:08:00–0:08:07
in unseren Routern, die uns das Internet liefern, der Web Server, auf den wir zugreifen, das
0:08:07–0:08:11
Betriebssystem oder einzelne Komponenten davon, die wir benutzen, also an ganz vielen Stellen
0:08:11–0:08:17
haben Entwickler ohne Geld dafür zu bekommen, gearbeitet und coole Ideen gehabt und jetzt
0:08:17–0:08:21
ist es eine gute Gelegenheit, da wieder etwas zurückzugeben.
0:08:21–0:08:26
Versuch das also mal und probier es mal aus, vielleicht macht es ja auch Spaß und was
0:08:26–0:08:31
auch noch ein Nebeneffekt natürlich ist, man lernt eine ganze Menge dazu und jetzt nicht
0:08:31–0:08:37
nur technischer Natur, also dass man zum Beispiel, wenn man sich in irgendetwas Neues einarbeitet,
0:08:37–0:08:42
weil das jetzt Thema dieses Problems ist, was man lösen möchte, sondern man lernt
0:08:42–0:08:48
auch zum Beispiel, wie jetzt ein solcher Pull-Request erstellt wird, lernt man hinzu,
0:08:48–0:08:52
das kann man bei ganz vielen unterschiedlichen Projekten wieder anwenden, man lernt auch
0:08:52–0:08:55
andere Leute kennen, also natürlich sind das jetzt keine Maschinen auf der anderen
0:08:55–0:09:01
Seite, sondern auch Wiederentwickler und kann dann also da auch Kontakte zu anderen Software-Entwicklern,
0:09:01–0:09:07
zu Designern, zu anderen kreativen Köpfen, zu Schreibern, zu einfach interessanten Leuten
0:09:07–0:09:08
dort aufbauen.
0:09:08–0:09:14
Ganz häufig passiert das in englischer Sprache, man trainiert also auch noch ein wenig sein
0:09:14–0:09:20
Englisch und an ganz unterschiedlichen Stellen würde man dann etwas dazu lernen, ohne dass
0:09:20–0:09:23
man das vielleicht im ersten Moment gedacht hätte.
0:09:23–0:09:29
Probier es aus, vielleicht macht es ja Spaß und würde mich freuen, wenn du da auch etwas
0:09:29–0:09:33
als Beitrag leisten könntest, ich probiere das auch immer mal wieder da mitzumachen.
0:09:33–0:09:39
Das Hektoberfest ist ja erst im Oktober, also noch ein wenig hin, wird dann eben über den
0:09:39–0:09:47
Oktober nochmal ein bisschen mehr gepusht, dass man das nochmal mehr in den Fokus der
0:09:47–0:09:52
Aufmerksamkeit stellt, dann gibt es auch Möglichkeiten da T-Shirts zu bekommen und so was, das soll
0:09:52–0:09:54
aber jetzt nicht das vorrangige Ziel sein.
0:09:54–0:10:00
Wichtiger oder interessanter ist es eigentlich, den eigenen Beitrag zu würdigen und noch mit
0:10:00–0:10:01
einzubauen.
0:10:01–0:10:09
Das war es erstmal wieder auch für mich, von dieser Seite für heute, ja ich wünsche
0:10:09–0:10:15
weiterhin eine symptomfreie Zeit, wascht euch die Hände, haltet Abstand und immer schön
0:10:15–0:10:18
die Maske tragen, bis dahin und tschüss.
2 Antworten auf „BF40: OpenSource Mitwirkung“
Ich fand es ein wenig schade, dass die Episode zwar mit dem Tenor „nicht unbedingt Spezial- oder Programmierkenntnisse notwendig“ startete, dann aber schnell doch in Richtung Programmierung ging – dabei gäbe es doch wirklich noch zahlreiche andere Möglichkeiten der Beteiligung.
Du hast absolut recht. Beim nachträglichen Durchhören ist mir das auch aufgefallen. Danke daher für deinen Link. 🙂