63 lines
2.4 KiB
Markdown
63 lines
2.4 KiB
Markdown
# Aufgabe 5
|
||
|
||
Hausaufgaben A4 bis 2.5.:
|
||
|
||
## Firmen beim Linux Infotag 2023
|
||
|
||
- **SUSE** Linux-Support für Unternehmen
|
||
- **IGEL Technology GmbH** Entwicklung eines kommerziellen Betriebssystems auf
|
||
Linux-Basis für Arbeitsplatzrechner
|
||
- **makandra GmbH** Individualentwicklung von Webanwendungen (hauptsächlich mittels Ruby
|
||
on Rails)
|
||
- **TUXEDO Computers** Verkauf von Laptops und PCs mit vorinstalliertem
|
||
Linux-Betriebssystem
|
||
|
||
## Open Data
|
||
|
||
Staatliche Institutionen sammeln und pflegen eine Vielzahl von Daten über das Land und
|
||
seine Bürger. Während diese Arbeit mit Steuermitteln finanziert wird, sind die Daten oft
|
||
nur für Behördenmitarbeiter und nicht für die Allgemeinheit nutzbar.
|
||
|
||
Open Data ist das Konzept, diese Daten unter einer freien Lizenz im Internet verfügbar
|
||
zu machen, sodass Unternehmen, Forscher und Privatpersonen die Daten in ihre eigenen
|
||
Anwendungen integrieren können.
|
||
|
||
Auch viele Unternehmen und Nichtregierungsorganisationen veröffentlichen Teile ihres
|
||
Datenbestandes. Dies kann auch wirtschaftliche Vorteile für das Unternehmen bieten,
|
||
beispielsweise die Förderund der Forschung an für das Unternehmen relevaten
|
||
Technologien.
|
||
|
||
Beispielsweise veröffentlicht die Deutsche Bahn Daten über alle ihre Bahnhöfe und
|
||
Haltestellen unter der CC BY 4.0-Lizenz.
|
||
|
||
Die Stadt Köln veröffentlicht seit 2010 Listen mit allen im jeweiligen Jahr vergebenen
|
||
Vornamen unter der
|
||
"[Datenlizenz Deutschland – Zero](https://www.govdata.de/dl-de/zero-2-0)" (ähnlich der
|
||
CC0-Lizenz).
|
||
|
||
## Make a Difference Without Making a Pull Request
|
||
|
||
Der Autor listet verschiedene Wege auf, an einem Open-Source-Projekt mitzuarbeiten, ohne
|
||
Code beizutragen.
|
||
|
||
1. Andere Beiträge (Pull-Requests) überprüfen
|
||
|
||
- Die Pull-Request testen und prüfen, ob der Fix/das neue Feature funktioniert
|
||
- Neuen Code und Dokumentationstext lesen und auf Fehler überprüfen
|
||
|
||
2. Das Projekt testen
|
||
|
||
- Die Software nutzen, Fehler dokumentieren und Issues erstellen
|
||
- Dokumentation korrekturlesen
|
||
- Accessibility sicherstellen
|
||
|
||
3. Issues triagieren
|
||
|
||
- Mit dem Ersteller kommunizieren und eventuelle Missverständnisse und fehlende
|
||
Informationen klären
|
||
- Prüfen, ob der Ersteller die aktuelle Version verwendet
|
||
- Auf Duplikate prüfen
|
||
- Das Issue korrekt benennen und formatieren
|
||
- Kategorisieren (Bug, Feature request, Spam, etc...)
|
||
- Für Bugs: nach einer Anleitung zum Reproduzieren fragen und selbst versuchen, den Bug
|
||
zu reproduzieren
|