Einstieg in Open Source

Wir alle haben irgendwann mal unsere Ersten Schritte in Open Source gemacht. In diesem Talk geht es zurück an den Anfang: Open Source Basics, wie Lizenzen oder Tools wie GitHub werden grundsätzlich für Einsteiger erklärt.

Transcript

1. Einstieg in Open Source Der Weg zum ersten Beitrag
2. Christoph Hochstrasser
3. Member seit 2008 75 eigene Repos, 111 insgesamt Erste Contribution 2011 @CHH
4. Warum überhaupt zu Open Source beitragen? Kurz noch bevor wir wirklich anfangen:
5. $$$?
6. Fame?
7. Welt verbessern. Auch kleine Beiträge bewirken etwas. Jeder Code der veröffentlich wird, kann anderen Personen helfen.
8. Zeig was du kannst. Du kannst bei Bewerbungen als Entwickler konkrete Werksproben präsentieren.
9. Experimentieren. Könnte es funktionieren?
10. Kreatives Programmieren Spaß am Programmieren erhalten, durch Entwickeln außerhalb von Kundenprojekten. Es muss nicht sinnvoll sein.
11. Basics
12. Definition von Open Source • Die Software liegt in einer für den Menschen lesbaren und verständlichen Form vor. • Die Software kann beliebig kopiert, verbreitet und genutzt werden. • Die Software darf verändert und in veränderter Form weitergegeben werden.
13. „Software” bezieht sich nicht nur auf Programme, kann auch z.B. ein Vertrag oder eine Grafik sein.
14. Begriffe
15. Maintainer Personen, die Projekte betreuen und das Recht haben Änderungen von Anderen freizugeben. Oft der Gründer des Projekts und für Richtungsentscheidungen verantwortlich.
16. Contributor Person, die zu einem Projekt beiträgt. Änderungen werden vom Maintainer freigegeben.
17. Versionskontrolle
18. Git Wichtigstes System
19. Linux Kernel Bekannt durch:
20. Änderungen an Dateien, die von mehreren Personen gemacht wurden, nachvollziehen können Warum braucht man Versionskontrolle?
21. Wichtige Begriffe
22. Repository Dateien mit Inhalten und dem Änderungsverlauf
23. Commit Änderung an einer oder an mehreren Dateien mit einer Beschreibung der Änderung
24. History Der Änderungsverlauf, in dem alle Änderungen an Dateien aufgelistet werden.
25. Branch Von engl. „Zweig”, also mehrere Änderungen zusammengefasst. Eine Branch kann von einer anderen weggezogen werden und Änderungen können auch wieder zurückgespielt werden.
26. Checkout Eine neue Branch als Kopie der aktuellen Branch erstellt.
27. Merge Die Commits der Branch werden mit einer anderen Branch zusammengeführt und Konflikte aufgelöst.
28. master Diese Branch hat jedes Git Repository standardmäßig.
29. Working Copy Die Dateien des Repository, mit denen du auf deinem PC arbeitest und die nur du siehst.
30. Origin Dein Repository, zugänglich im Internet, wo Änderungen auch von anderen gesehen werden können, z.B. auf GitHub oder BitBucket.
31. Push Commits in der Working Copy werden zur Origin übertragen.
32. Pull Commits in der Origin werden in deine Working Copy übertragen.
33. GitHub Embrace, Extend, Extinguish
34. Führende Plattform für das Veröffentlichen von Open Source Code
35. Seit 2018 Teil von Microsoft
36. Features • Öffentliche und private Git Repositories (seit 2019 auch ohne Abo unendlich viele private Repositories) • Issues (Tickets) • Projects (Boards) • Pull Requests • Forks • Stars (Favoriten) • Wiki • Releases (Changelog) • Statistiken • Gists
37. GitHub Repository Demo
38. Konventionen in Open Source Repositories
39. README Zentrale Anlaufstelle in einem Projekt
40. LICENSE Die Lizenz des Projekts — sprich: Was darf ich damit machen?
41. CONTRIBUTING Informationen für Contributors (Beitragende) zum Projekt.
42. „src” oder „lib” Der Code des Projekts
43. „test” oder „tests” Automatisierte Tests
44. examples Beispielcode
45. docs Dokumentation, falls nicht in einem eigenen Repository.
46. Vue.js Repository Demo
47. Lizenzen I am not a lawyer!
48. Warum? Du hast grundsätzlich das Urheberrecht auf Werke, die du verfasst. Auch Code ist ein Werk, genauso wie Shakespeare.
49. Das heißt, ohne deine Zustimmung, darf niemand etwas mit deinem Code tun. Nichts, nada. Kein Verwenden, kein Bearbeiten, kein Weitergeben.
50. Wie geben wir jetzt jedem das Recht, mit dem Code etwas zu machen? Sprich: Wie machen wir ihn Open Source?
51. Dafür gibt es Lizenzen. Lizenz = Vereinbarung, wo drinnen steht, was jemand anderer außer dir, mit dem Code (Werk) machen darf und was nicht.
52. Bekannte Lizenzen
53. General Public License (GPL) Bekannt durch den Linux Kernel oder WordPress. Veränderter GPL Code muss wieder unter der GPL veröffentlicht werden. Veränderter Code muss öffentlich zur Verfügung gestellt werden.
54. MIT License Sehr oft in der JavaScript Community eingesetzt und sehr einfach. Jeder darf im Prinzip alles machen, keine Ansprüche auf Gewährleistung. Beispiele: Rails, Vue.js, Laravel
55. Apache License Sehr beliebt bei Firmen, weil ein Kompromiss zwischen Ausführlichkeit und Freiheiten.
56. Creative Commons Hauptsächlich für Grafiken, Schriften, Texte, ganze Websites. Verbot von kommerzieller Nutzung möglich. Namensnennung erzwingbar.
57. Mehr auf: https://opensource.org/ licenses Dort findest du alle Lizenzen.
58. Was kannst du beitragen?
59. Keine Programmierkenntnisse notwendig
60. 1 Lies die Dokumentation
61. 2 Achte auf Rechtschreibfehler, Tippfehler oder wo etwas verständlicher erklärt werden könnte. Auch die Besten machen Fehler.
62. 3 Fehler beheben und einreichen über den Online-Editor von GitHub
63. Du hast Programmierkenntnisse
64. 1 Sieh dir die offenen Issues auf GitHub an
65. 2 Achte auf Labels, wie „Good First Issue” oder „Help Wanted”
66. 3 Fork
67. 4 CONTRIBUTING lesen
68. 5 Änderungen machen und testen
69. 6 Pull Request senden
70. Pull Request Demo
71. Tipps
72. Nett zueinander sein Die meisten Menschen betreuen Projekte in ihrer Freizeit.
73. Be humble Die Maintainer müssen das Projekt langfristig für viele User betreuen, nimm ihre Rückmeldungen ernst.
74. Halte dich an den Coding Style Erspare dem Maintainer Zeit, in dem du dich an den Style hältst der im Projekt verwendet wird.
75. Vermeide große Pull Requests Änderungen an großen Pull Requests sind schwer nachzuvollziehen, die Wahrscheinlichkeit besteht, dass der PR einfach abgelehnt wird.
76. Orientiere dich an den Präferenzen des Projekts Um deine eigenen Präferenzen auszuleben kannst du jederzeit dein eigenes Projekt starten.
77. Zuerst denken, dann schreiben. Alles, was du schreibst, muss auch jemand lesen. Versuche nur so viele Kommentare wie notwendig zu schreiben. Bleib beim Thema.
78. Versuche dich mit automatisierten Testen zu beschäftigen Wird in fast jedem Code-Projekt verwendet und Maintainer fordern gerne Tests zu Änderungen.
79. Nicht jeder Pull Request wird angenommen werden. Das ist OK. Maintainer müssen auf die Bedürfnisse von vielen Usern achten. Falls du spezielle Anforderungen hast, dann steht es dir frei einen Fork zu machen.
80. Nützliche Ressourcen • Open-Source Guide https://opensource.guide • GitHub Hilfe: https://help.github.com • Hilfe bei der Wahl der Lizenz: https:// choosealicense.com
81. Über mich
82. Gute Software entsteht durch gute Systeme.
83. Twitter @hochchristoph Facebook facebook.com/christoph.hochstrasser Github @CHH Web christophh.net hochstrasser.io
84. Welche Fragen habt ihr?
85. christoph@hochstrasser.io Wenn dir noch eine Frage einfällt: