Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Einstieg in Open Source

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.

A74f50459192654b891771cc63e401b6?s=128

Christoph Hochstrasser

January 16, 2019
Tweet

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: