Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 Nicolai Kamenzky, Seminar „Komponenten“ Einfluss gewinnen Nicolai Kamenzky Freie Universität Berlin, Institut für Informatik.

Ähnliche Präsentationen


Präsentation zum Thema: "1 Nicolai Kamenzky, Seminar „Komponenten“ Einfluss gewinnen Nicolai Kamenzky Freie Universität Berlin, Institut für Informatik."—  Präsentation transkript:

1 1 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Seminar „Komponenten“ Einfluss gewinnen Nicolai Kamenzky Freie Universität Berlin, Institut für Informatik http://www.inf.fu-berlin.de/inst/ag-se/ http://www.inf.fu-berlin.de/inst/ag-se/ Worum geht es? Das Freenet Projekt Das Python Projekt Zusammenfassung

2 2 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Worum geht es? Teilnahme an einem Open Source Software (OSS) Projekt

3 3 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Worum geht es? Teilnahme an einem Open Source Software (OSS) Projekt Ausgangspunkt

4 4 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Worum geht es? Teilnahme an einem Open Source Software (OSS) Projekt Ausgangspunkt: Interesse an der Mitwirkung

5 5 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Worum geht es? Teilnahme an einem Open Source Software (OSS) Projekt Ausgangspunkt: Interesse an der Mitwirkung Ziel

6 6 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Worum geht es? Teilnahme an einem Open Source Software (OSS) Projekt Ausgangspunkt: Interesse an der Mitwirkung Ziel: Mitglied der Gemeinschaft mit gewünschtem Einfluss

7 7 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Worum geht es? Teilnahme an einem Open Source Software (OSS) Projekt Ausgangspunkt: Interesse an der Mitwirkung Ziel: Mitglied der Gemeinschaft mit gewünschtem Einfluss Gewünschter Einfluss?

8 8 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Worum geht es? Teilnahme an einem Open Source Software (OSS) Projekt Ausgangspunkt: Interesse an der Mitwirkung Ziel: Mitglied der Gemeinschaft mit gewünschtem Einfluss Gewünschter Einfluss? Betrachtungswinkel

9 9 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Worum geht es? Teilnahme an einem Open Source Software (OSS) Projekt Ausgangspunkt: Interesse an der Mitwirkung Ziel: Mitglied der Gemeinschaft mit gewünschtem Einfluss Gewünschter Einfluss? Betrachtungswinkel:  Wunsch zur Mitgestaltung der Software

10 10 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Worum geht es? Teilnahme an einem Open Source Software (OSS) Projekt Ausgangspunkt: Interesse an der Mitwirkung Ziel: Mitglied der Gemeinschaft mit gewünschtem Einfluss Gewünschter Einfluss? Betrachtungswinkel:  Wunsch zur Mitgestaltung der Software Einbau von Features

11 11 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Worum geht es? Teilnahme an einem Open Source Software (OSS) Projekt Ausgangspunkt: Interesse an der Mitwirkung Ziel: Mitglied der Gemeinschaft mit gewünschtem Einfluss Gewünschter Einfluss? Betrachtungswinkel:  Wunsch zur Mitgestaltung der Software Einbau von Features Gestaltung der Anforderungen an die Software

12 12 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Worum geht es? Teilnahme an einem Open Source Software (OSS) Projekt Ausgangspunkt: Interesse an der Mitwirkung Ziel: Mitglied der Gemeinschaft mit gewünschtem Einfluss Gewünschter Einfluss? Betrachtungswinkel:  Wunsch zur Mitgestaltung der Software Einbau von Features Gestaltung der Anforderungen an die Software  Ein werdender Entwickler

13 13 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Motivation zur Betrachtung der Thematik

14 14 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Motivation zur Betrachtung der Thematik Für das Projekt:

15 15 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Motivation zur Betrachtung der Thematik Für das Projekt:  Mangel an Arbeitskraft.

16 16 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Motivation zur Betrachtung der Thematik Für das Projekt:  Mangel an Arbeitskraft.  Erfolg steht im Zusammenhang mit der Mitgliederzahl.

17 17 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Motivation zur Betrachtung der Thematik Für das Projekt:  Mangel an Arbeitskraft.  Erfolg steht im Zusammenhang mit der Mitgliederzahl. Für das werdende Mitglied:

18 18 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Motivation zur Betrachtung der Thematik Für das Projekt:  Mangel an Arbeitskraft.  Erfolg steht im Zusammenhang mit der Mitgliederzahl. Für das werdende Mitglied:  Ziel: Einfluss persönlicher Anforderungen an die Software.

19 19 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Motivation zur Betrachtung der Thematik Für das Projekt:  Mangel an Arbeitskraft.  Erfolg steht im Zusammenhang mit der Mitgliederzahl. Für das werdende Mitglied:  Ziel: Einfluss persönlicher Anforderungen an die Software.  Die OSS Gemeinschaft lässt nicht jeden an das CVS.

20 20 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Motivation zur Betrachtung der Thematik Für das Projekt:  Mangel an Arbeitskraft.  Erfolg steht im Zusammenhang mit der Mitgliederzahl. Für das werdende Mitglied:  Ziel: Einfluss persönlicher Anforderungen an die Software.  Die OSS Gemeinschaft lässt nicht jeden an das CVS.  Beweis der „Richtige“ zu sein, wird verlangt.

21 21 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Motivation zur Betrachtung der Thematik Für das Projekt:  Mangel an Arbeitskraft.  Erfolg steht im Zusammenhang mit der Mitgliederzahl. Für das werdende Mitglied:  Ziel: Einfluss persönlicher Anforderungen an die Software.  Die OSS Gemeinschaft lässt nicht jeden an das CVS.  Beweis der „Richtige“ zu sein, wird verlangt.  Aber wie?

22 22 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Motivation zur Betrachtung der Thematik Für das Projekt:  Mangel an Arbeitskraft.  Erfolg steht im Zusammenhang mit der Mitgliederzahl. Für das werdende Mitglied:  Ziel: Einfluss persönlicher Anforderungen an die Software.  Die OSS Gemeinschaft lässt nicht jeden an das CVS.  Beweis der „Richtige“ zu sein, wird verlangt.  Aber wie?  Dazu ist ein Lernprozess nötig.

23 23 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Motivation zur Betrachtung der Thematik Für das Projekt:  Mangel an Arbeitskraft.  Erfolg steht im Zusammenhang mit der Mitgliederzahl. Für das werdende Mitglied:  Ziel: Einfluss persönlicher Anforderungen an die Software.  Die OSS Gemeinschaft lässt nicht jeden an das CVS.  Beweis der „Richtige“ zu sein, wird verlangt.  Aber wie?  Dazu ist ein Lernprozess nötig.  Daran scheitern viele!

24 24 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Definitionen

25 25 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Definitionen Listenteilnehmer

26 26 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Definitionen Listenteilnehmer  Benutzer der Software

27 27 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Definitionen Listenteilnehmer  Benutzer der Software  Teilnehmer in allgemeinen Diskussionen

28 28 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Definitionen Listenteilnehmer  Benutzer der Software  Teilnehmer in allgemeinen Diskussionen Entwickler

29 29 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Definitionen Listenteilnehmer  Benutzer der Software  Teilnehmer in allgemeinen Diskussionen Entwickler  Zur Entwicklung des OSS Projektes beitragende Mitglieder

30 30 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Definitionen Listenteilnehmer  Benutzer der Software  Teilnehmer in allgemeinen Diskussionen Entwickler  Zur Entwicklung des OSS Projektes beitragende Mitglieder Neulinge

31 31 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Definitionen Listenteilnehmer  Benutzer der Software  Teilnehmer in allgemeinen Diskussionen Entwickler  Zur Entwicklung des OSS Projektes beitragende Mitglieder Neulinge  An der Entwicklung interessierte Personen

32 32 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Definitionen Listenteilnehmer  Benutzer der Software  Teilnehmer in allgemeinen Diskussionen Entwickler  Zur Entwicklung des OSS Projektes beitragende Mitglieder Neulinge  An der Entwicklung interessierte Personen Mit dem Erhalt der CVS Schreibrechte wird ein Neuling zum Einsteiger.

33 33 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Definitionen Listenteilnehmer  Benutzer der Software  Teilnehmer in allgemeinen Diskussionen Entwickler  Zur Entwicklung des OSS Projektes beitragende Mitglieder Neulinge  An der Entwicklung interessierte Personen Mit dem Erhalt der CVS Schreibrechte wird ein Neuling zum Einsteiger. Einsteiger

34 34 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Definitionen Listenteilnehmer  Benutzer der Software  Teilnehmer in allgemeinen Diskussionen Entwickler  Zur Entwicklung des OSS Projektes beitragende Mitglieder Neulinge  An der Entwicklung interessierte Personen Mit dem Erhalt der CVS Schreibrechte wird ein Neuling zum Einsteiger. Einsteiger  Neu in die Entwicklergruppe aufgenommene Mitglieder

35 35 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling verlangt?

36 36 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling verlangt? Die Art der entwickelten Software verlangt Fachwissen.

37 37 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling verlangt? Die Art der entwickelten Software verlangt Fachwissen. Je nach Teilbereich der Software braucht man z.B.:

38 38 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling verlangt? Die Art der entwickelten Software verlangt Fachwissen. Je nach Teilbereich der Software braucht man z.B.:  Kenntnis einer bestimmen Programmiersprache

39 39 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling verlangt? Die Art der entwickelten Software verlangt Fachwissen. Je nach Teilbereich der Software braucht man z.B.:  Kenntnis einer bestimmen Programmiersprache  Mehr oder weniger Mathematikkenntnisse

40 40 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling verlangt? Die Art der entwickelten Software verlangt Fachwissen. Je nach Teilbereich der Software braucht man z.B.:  Kenntnis einer bestimmen Programmiersprache  Mehr oder weniger Mathematikkenntnisse ...

41 41 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling verlangt? Die Art der entwickelten Software verlangt Fachwissen. Je nach Teilbereich der Software braucht man z.B.:  Kenntnis einer bestimmen Programmiersprache  Mehr oder weniger Mathematikkenntnisse ... Einarbeitung in die bestehende Software nötig.

42 42 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling verlangt? Die Art der entwickelten Software verlangt Fachwissen. Je nach Teilbereich der Software braucht man z.B.:  Kenntnis einer bestimmen Programmiersprache  Mehr oder weniger Mathematikkenntnisse ... Einarbeitung in die bestehende Software nötig. Dies sind die technischen Anforderungen.

43 43 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Freenet Projekt

44 44 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Freenet Projekt P2P-System  hochskalierbar, anonym, dezentralisiert

45 45 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Freenet Projekt P2P-System  hochskalierbar, anonym, dezentralisiert Im Jahre 1999 von Ian Clarke gegründet.

46 46 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Freenet Projekt P2P-System  hochskalierbar, anonym, dezentralisiert Im Jahre 1999 von Ian Clarke gegründet. Ausgangspunkt waren seine theoretischen Überlegungen.

47 47 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Freenet Projekt P2P-System  hochskalierbar, anonym, dezentralisiert Im Jahre 1999 von Ian Clarke gegründet. Ausgangspunkt waren seine theoretischen Überlegungen. Von Krogh, Spaeth und Lakhani haben das Projekt in seinem ersten Jahr (2000) studiert.

48 48 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Spezialisierung Projekt wurde in Module gegliedert.

49 49 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Spezialisierung Projekt wurde in Module gegliedert. Welche Module wurden bearbeitet?

50 50 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Spezialisierung Projekt wurde in Module gegliedert. Welche Module wurden bearbeitet?

51 51 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Spezialisierung Projekt wurde in Module gegliedert. Welche Module wurden bearbeitet? Modul 3: Kryptographie Modul 7: Clients (GUI) Modul 9: Build & Install

52 52 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Gründe zur Spezialisierung

53 53 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Gründe zur Spezialisierung Schwierigkeitsgrad des Änderns oder Entwickelns eines Moduls

54 54 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Gründe zur Spezialisierung Schwierigkeitsgrad des Änderns oder Entwickelns eines Moduls  Das Kryptographiemodul ist schwer.

55 55 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Gründe zur Spezialisierung Schwierigkeitsgrad des Änderns oder Entwickelns eines Moduls  Das Kryptographiemodul ist schwer. Wahlfreiheit der verwendeten Programmiersprache

56 56 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Gründe zur Spezialisierung Schwierigkeitsgrad des Änderns oder Entwickelns eines Moduls  Das Kryptographiemodul ist schwer. Wahlfreiheit der verwendeten Programmiersprache  Die Installation kann in versch. Sprachen geschrieben sein.

57 57 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Gründe zur Spezialisierung Schwierigkeitsgrad des Änderns oder Entwickelns eines Moduls  Das Kryptographiemodul ist schwer. Wahlfreiheit der verwendeten Programmiersprache  Die Installation kann in versch. Sprachen geschrieben sein. Schwierigkeitsgrad der Integrierung des Moduls in die Softwarearchitektur

58 58 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Gründe zur Spezialisierung Schwierigkeitsgrad des Änderns oder Entwickelns eines Moduls  Das Kryptographiemodul ist schwer. Wahlfreiheit der verwendeten Programmiersprache  Die Installation kann in versch. Sprachen geschrieben sein. Schwierigkeitsgrad der Integrierung des Moduls in die Softwarearchitektur  Das Interface zwischen dem Build & Install Modul und dem Rest des Systems ist klar definiert.

59 59 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Gründe zur Spezialisierung Schwierigkeitsgrad des Änderns oder Entwickelns eines Moduls  Das Kryptographiemodul ist schwer. Wahlfreiheit der verwendeten Programmiersprache  Die Installation kann in versch. Sprachen geschrieben sein. Schwierigkeitsgrad der Integrierung des Moduls in die Softwarearchitektur  Das Interface zwischen dem Build & Install Modul und dem Rest des Systems ist klar definiert. Außmaß der Zusammenarbeit oder Unabhängigkeit der Module

60 60 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Gründe zur Spezialisierung Schwierigkeitsgrad des Änderns oder Entwickelns eines Moduls  Das Kryptographiemodul ist schwer. Wahlfreiheit der verwendeten Programmiersprache  Die Installation kann in versch. Sprachen geschrieben sein. Schwierigkeitsgrad der Integrierung des Moduls in die Softwarearchitektur  Das Interface zwischen dem Build & Install Modul und dem Rest des Systems ist klar definiert. Außmaß der Zusammenarbeit oder Unabhängigkeit der Module  Funktioniert die Kryptographie nicht, funktioniert das ganze System nicht.

61 61 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Gründe zur Spezialisierung Schwierigkeitsgrad des Änderns oder Entwickelns eines Moduls  Das Kryptographiemodul ist schwer. Wahlfreiheit der verwendeten Programmiersprache  Die Installation kann in versch. Sprachen geschrieben sein. Schwierigkeitsgrad der Integrierung des Moduls in die Softwarearchitektur  Das Interface zwischen dem Build & Install Modul und dem Rest des Systems ist klar definiert. Außmaß der Zusammenarbeit oder Unabhängigkeit der Module  Funktioniert die Kryptographie nicht, funktioniert das ganze System nicht. Dies sind Beitragsbarrieren.

62 62 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Beitragsbarrieren Der Hinderungsgrad einer Beitragsbarriere hängt von den technischen Fähigkeiten der Person ab.

63 63 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Beitragsbarrieren Der Hinderungsgrad einer Beitragsbarriere hängt von den technischen Fähigkeiten der Person ab. Die technischen Fähigkeiten können wiederum vom Grad des Verständnisses vom Softwaresystem abhängen.

64 64 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Beitragsbarrieren Der Hinderungsgrad einer Beitragsbarriere hängt von den technischen Fähigkeiten der Person ab. Die technischen Fähigkeiten können wiederum vom Grad des Verständnisses vom Softwaresystem abhängen. Der Neuling muss sich schrittweise einarbeiten.

65 65 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Beitragsbarrieren Der Hinderungsgrad einer Beitragsbarriere hängt von den technischen Fähigkeiten der Person ab. Die technischen Fähigkeiten können wiederum vom Grad des Verständnisses vom Softwaresystem abhängen. Der Neuling muss sich schrittweise einarbeiten.  Beobachten der technischen Diskussionen

66 66 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Beitragsbarrieren Der Hinderungsgrad einer Beitragsbarriere hängt von den technischen Fähigkeiten der Person ab. Die technischen Fähigkeiten können wiederum vom Grad des Verständnisses vom Softwaresystem abhängen. Der Neuling muss sich schrittweise einarbeiten.  Beobachten der technischen Diskussionen  Teilnahme an den technischen Diskussionen

67 67 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Beitragsbarrieren Der Hinderungsgrad einer Beitragsbarriere hängt von den technischen Fähigkeiten der Person ab. Die technischen Fähigkeiten können wiederum vom Grad des Verständnisses vom Softwaresystem abhängen. Der Neuling muss sich schrittweise einarbeiten.  Beobachten der technischen Diskussionen  Teilnahme an den technischen Diskussionen  Fehlerbehebung in der Software

68 68 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Beitragsbarrieren Der Hinderungsgrad einer Beitragsbarriere hängt von den technischen Fähigkeiten der Person ab. Die technischen Fähigkeiten können wiederum vom Grad des Verständnisses vom Softwaresystem abhängen. Der Neuling muss sich schrittweise einarbeiten.  Beobachten der technischen Diskussionen  Teilnahme an den technischen Diskussionen  Fehlerbehebung in der Software Dabei sinken für ihn die Beitragsbarrieren.

69 69 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Lernen in der Praxis Diese Vorgehensweise ist ein ‘Lernen in der Praxis’.

70 70 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Lernen in der Praxis Diese Vorgehensweise ist ein ‘Lernen in der Praxis’. Vergleichbar mit Lernprozess eines Azubis.

71 71 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Lernen in der Praxis Diese Vorgehensweise ist ein ‘Lernen in der Praxis’. Vergleichbar mit Lernprozess eines Azubis. Im Unterschied werden Neulinge nicht unterrichtet.

72 72 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Lernen in der Praxis Diese Vorgehensweise ist ein ‘Lernen in der Praxis’. Vergleichbar mit Lernprozess eines Azubis. Im Unterschied werden Neulinge nicht unterrichtet. Selbstständige Einarbeitung nötig.

73 73 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Lernen in der Praxis Diese Vorgehensweise ist ein ‘Lernen in der Praxis’. Vergleichbar mit Lernprozess eines Azubis. Im Unterschied werden Neulinge nicht unterrichtet. Selbstständige Einarbeitung nötig. Währenddessen sind sie Randmitglieder.

74 74 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Lernen in der Praxis Diese Vorgehensweise ist ein ‘Lernen in der Praxis’. Vergleichbar mit Lernprozess eines Azubis. Im Unterschied werden Neulinge nicht unterrichtet. Selbstständige Einarbeitung nötig. Währenddessen sind sie Randmitglieder. Sie streben eine Vollmitgliedschaft an.

75 75 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Lernen in der Praxis Diese Vorgehensweise ist ein ‘Lernen in der Praxis’. Vergleichbar mit Lernprozess eines Azubis. Im Unterschied werden Neulinge nicht unterrichtet. Selbstständige Einarbeitung nötig. Währenddessen sind sie Randmitglieder. Sie streben eine Vollmitgliedschaft an.  Mitglied der Entwicklergemeinschaft

76 76 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Lernen in der Praxis Diese Vorgehensweise ist ein ‘Lernen in der Praxis’. Vergleichbar mit Lernprozess eines Azubis. Im Unterschied werden Neulinge nicht unterrichtet. Selbstständige Einarbeitung nötig. Währenddessen sind sie Randmitglieder. Sie streben eine Vollmitgliedschaft an.  Mitglied der Entwicklergemeinschaft  Verständnis des kompletten Softwaresystems

77 77 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Lernen in der Praxis Diese Vorgehensweise ist ein ‘Lernen in der Praxis’. Vergleichbar mit Lernprozess eines Azubis. Im Unterschied werden Neulinge nicht unterrichtet. Selbstständige Einarbeitung nötig. Währenddessen sind sie Randmitglieder. Sie streben eine Vollmitgliedschaft an.  Mitglied der Entwicklergemeinschaft  Verständnis des kompletten Softwaresystems  Beitrag zu wichtigen Diskussionen über das Projekt

78 78 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Lernen in der Praxis Diese Vorgehensweise ist ein ‘Lernen in der Praxis’. Vergleichbar mit Lernprozess eines Azubis. Im Unterschied werden Neulinge nicht unterrichtet. Selbstständige Einarbeitung nötig. Währenddessen sind sie Randmitglieder. Sie streben eine Vollmitgliedschaft an.  Mitglied der Entwicklergemeinschaft  Verständnis des kompletten Softwaresystems  Beitrag zu wichtigen Diskussionen über das Projekt Person kann auch Randmitglied bleiben wollen.

79 79 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling noch verlangt?

80 80 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling noch verlangt? Die Mitglieder eines OSS Projektes bilden eine soziale Gemeinschaft.

81 81 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling noch verlangt? Die Mitglieder eines OSS Projektes bilden eine soziale Gemeinschaft. Die Arbeit beruht auf Gegenseitigkeit.

82 82 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling noch verlangt? Die Mitglieder eines OSS Projektes bilden eine soziale Gemeinschaft. Die Arbeit beruht auf Gegenseitigkeit. Die Arbeit sollte recht reibungslos funktionieren.

83 83 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling noch verlangt? Die Mitglieder eines OSS Projektes bilden eine soziale Gemeinschaft. Die Arbeit beruht auf Gegenseitigkeit. Die Arbeit sollte recht reibungslos funktionieren. Deshalb sollten gemeinsame Vorstellungen und Ziele vertreten werden.

84 84 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling noch verlangt? Die Mitglieder eines OSS Projektes bilden eine soziale Gemeinschaft. Die Arbeit beruht auf Gegenseitigkeit. Die Arbeit sollte recht reibungslos funktionieren. Deshalb sollten gemeinsame Vorstellungen und Ziele vertreten werden. (Dies ist auch der Fall.)

85 85 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling noch verlangt? Die Mitglieder eines OSS Projektes bilden eine soziale Gemeinschaft. Die Arbeit beruht auf Gegenseitigkeit. Die Arbeit sollte recht reibungslos funktionieren. Deshalb sollten gemeinsame Vorstellungen und Ziele vertreten werden. (Dies ist auch der Fall.) Der Neuling muss sich diesen anpassen.

86 86 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling noch verlangt? Die Mitglieder eines OSS Projektes bilden eine soziale Gemeinschaft. Die Arbeit beruht auf Gegenseitigkeit. Die Arbeit sollte recht reibungslos funktionieren. Deshalb sollten gemeinsame Vorstellungen und Ziele vertreten werden. (Dies ist auch der Fall.) Der Neuling muss sich diesen anpassen. Dies sind die sozialen Anforderungen.

87 87 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Die epistemische Gemeinschaft Die OSS Gemeinschaft wird als epistemische (ergebnis- orientierte) Gemeinschaft verstanden.

88 88 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Die epistemische Gemeinschaft Die OSS Gemeinschaft wird als epistemische (ergebnis- orientierte) Gemeinschaft verstanden. Primäre Motivation

89 89 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Die epistemische Gemeinschaft Die OSS Gemeinschaft wird als epistemische (ergebnis- orientierte) Gemeinschaft verstanden. Primäre Motivation: Erfüllung des persönlichen Anspruchs der einzelnen Mitglieder an die Software.

90 90 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Die epistemische Gemeinschaft Die OSS Gemeinschaft wird als epistemische (ergebnis- orientierte) Gemeinschaft verstanden. Primäre Motivation: Erfüllung des persönlichen Anspruchs der einzelnen Mitglieder an die Software. Eine epistemische Gemeinschaft hat folgende Eigenschaften:

91 91 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Die epistemische Gemeinschaft Die OSS Gemeinschaft wird als epistemische (ergebnis- orientierte) Gemeinschaft verstanden. Primäre Motivation: Erfüllung des persönlichen Anspruchs der einzelnen Mitglieder an die Software. Eine epistemische Gemeinschaft hat folgende Eigenschaften:  Gemeinsame Normen und Werte

92 92 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Die epistemische Gemeinschaft Die OSS Gemeinschaft wird als epistemische (ergebnis- orientierte) Gemeinschaft verstanden. Primäre Motivation: Erfüllung des persönlichen Anspruchs der einzelnen Mitglieder an die Software. Eine epistemische Gemeinschaft hat folgende Eigenschaften:  Gemeinsame Normen und Werte  Gemeinsame Vorstellungen über das Vorgehen

93 93 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Die epistemische Gemeinschaft Die OSS Gemeinschaft wird als epistemische (ergebnis- orientierte) Gemeinschaft verstanden. Primäre Motivation: Erfüllung des persönlichen Anspruchs der einzelnen Mitglieder an die Software. Eine epistemische Gemeinschaft hat folgende Eigenschaften:  Gemeinsame Normen und Werte  Gemeinsame Vorstellungen über das Vorgehen  Gemeinsame Bewertungsmaßstäbe

94 94 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Die epistemische Gemeinschaft Die OSS Gemeinschaft wird als epistemische (ergebnis- orientierte) Gemeinschaft verstanden. Primäre Motivation: Erfüllung des persönlichen Anspruchs der einzelnen Mitglieder an die Software. Eine epistemische Gemeinschaft hat folgende Eigenschaften:  Gemeinsame Normen und Werte  Gemeinsame Vorstellungen über das Vorgehen  Gemeinsame Bewertungsmaßstäbe  Gemeinsame Projektziele

95 95 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Die epistemische Gemeinschaft Die OSS Gemeinschaft wird als epistemische (ergebnis- orientierte) Gemeinschaft verstanden. Primäre Motivation: Erfüllung des persönlichen Anspruchs der einzelnen Mitglieder an die Software. Eine epistemische Gemeinschaft hat folgende Eigenschaften:  Gemeinsame Normen und Werte  Gemeinsame Vorstellungen über das Vorgehen  Gemeinsame Bewertungsmaßstäbe  Gemeinsame Projektziele Erfüllen die Mitglieder die Eigenschaften weitgehend, funktioniert die Zusammenarbeit reibungsloser.

96 96 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Die epistemische Gemeinschaft Die OSS Gemeinschaft wird als epistemische (ergebnis- orientierte) Gemeinschaft verstanden. Primäre Motivation: Erfüllung des persönlichen Anspruchs der einzelnen Mitglieder an die Software. Eine epistemische Gemeinschaft hat folgende Eigenschaften:  Gemeinsame Normen und Werte  Gemeinsame Vorstellungen über das Vorgehen  Gemeinsame Bewertungsmaßstäbe  Gemeinsame Projektziele Erfüllen die Mitglieder die Eigenschaften weitgehend, funktioniert die Zusammenarbeit reibungsloser.

97 97 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Python Projekt

98 98 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Python Projekt Programmiersprache für viele Plattformen

99 99 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Python Projekt Programmiersprache für viele Plattformen  Interpretiert, objekt-orientiert

100 100 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Python Projekt Programmiersprache für viele Plattformen  Interpretiert, objekt-orientiert  Enfach zu erlernen und zu lesen.

101 101 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Python Projekt Programmiersprache für viele Plattformen  Interpretiert, objekt-orientiert  Enfach zu erlernen und zu lesen. Ab 1990 von Guido v. Rossum entwickelt.

102 102 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Python Projekt Programmiersprache für viele Plattformen  Interpretiert, objekt-orientiert  Enfach zu erlernen und zu lesen. Ab 1990 von Guido v. Rossum entwickelt. Im Jahre 2000 unter die GPL gestellt.

103 103 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Python Projekt Programmiersprache für viele Plattformen  Interpretiert, objekt-orientiert  Enfach zu erlernen und zu lesen. Ab 1990 von Guido v. Rossum entwickelt. Im Jahre 2000 unter die GPL gestellt. Nicolas Ducheneaut hat die Projektentwicklung im Jahre 2002 analysiert.

104 104 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Offengelegte Anforderungen auf der Webseite

105 105 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Offengelegte Anforderungen auf der Webseite Um mit dieser großen und verstreuten Gruppe zu arbeiten, musst du lernen, wer die richtige Ansprechperson ist, wie du andere Entwickler vom Nutzen deiner Quellcodeänderung überzeugst, wie du hilfreiche Kritik lieferst und wie du Kritik annehmen musst.

106 106 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Offengelegte Anforderungen auf der Webseite Um mit dieser großen und verstreuten Gruppe zu arbeiten, musst du lernen, wer die richtige Ansprechperson ist, wie du andere Entwickler vom Nutzen deiner Quellcodeänderung überzeugst, wie du hilfreiche Kritik lieferst und wie du Kritik annehmen musst. Wenn die Python Entwicklergruppe weiß wer du bist, entweder durch die Diskussionen auf der Mailingliste, wegen der Lieferungen von Quellcode oder durch andere Interaktionen, darfst du eine CVS Zugriffserlaubnis erfragen.

107 107 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Der OSS Project Browser Um den Grad des Einflusses einer Person zu visualisieren, hat Ducheneaut ein Programm entwickelt.

108 108 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Der OSS Project Browser Um den Grad des Einflusses einer Person zu visualisieren, hat Ducheneaut ein Programm entwickelt. Es stellt ein Netz aus Beziehungen dar.

109 109 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 1

110 110 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 1 Er beobachtete die Mailingliste.

111 111 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 1 Er beobachtete die Mailingliste.  Absorption der Normen und Werte der Gemeinschaft.

112 112 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 1 Er beobachtete die Mailingliste.  Absorption der Normen und Werte der Gemeinschaft. Erste Nachricht im Beobachtungszeitraum betraf einen technischen Belang.

113 113 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 1 Er beobachtete die Mailingliste.  Absorption der Normen und Werte der Gemeinschaft. Erste Nachricht im Beobachtungszeitraum betraf einen technischen Belang.  So wurde er für die Gemeinschaft sichtbar.

114 114 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 1 Er beobachtete die Mailingliste.  Absorption der Normen und Werte der Gemeinschaft. Erste Nachricht im Beobachtungszeitraum betraf einen technischen Belang.  So wurde er für die Gemeinschaft sichtbar.

115 115 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 2 Durch seine Arbeit mit Python fand er zunehmend Fehler.

116 116 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 2 Durch seine Arbeit mit Python fand er zunehmend Fehler. Er berichtete sie.

117 117 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 2 Durch seine Arbeit mit Python fand er zunehmend Fehler. Er berichtete sie. Er fügte meist auch Patches als Bugfix bei.

118 118 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 2 Durch seine Arbeit mit Python fand er zunehmend Fehler. Er berichtete sie. Er fügte meist auch Patches als Bugfix bei. Er bekam den Ruf ein guter Bugfixer zu sein.

119 119 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 2 Durch seine Arbeit mit Python fand er zunehmend Fehler. Er berichtete sie. Er fügte meist auch Patches als Bugfix bei. Er bekam den Ruf ein guter Bugfixer zu sein. Ihm wurde der CVS Zugriff gewährt.

120 120 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 2 Durch seine Arbeit mit Python fand er zunehmend Fehler. Er berichtete sie. Er fügte meist auch Patches als Bugfix bei. Er bekam den Ruf ein guter Bugfixer zu sein. Ihm wurde der CVS Zugriff gewährt.

121 121 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 3 Er nahm nun erste, kleine Änderungen an der Softwarearchitektur vor.

122 122 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 3 Er nahm nun erste, kleine Änderungen an der Softwarearchitektur vor. Er schlug vor, seine selbstprogrammierte Bibliothek in die Standardbibliothek zu integrieren.

123 123 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 3 Er nahm nun erste, kleine Änderungen an der Softwarearchitektur vor. Er schlug vor, seine selbstprogrammierte Bibliothek in die Standardbibliothek zu integrieren.

124 124 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 3 Er nahm nun erste, kleine Änderungen an der Softwarearchitektur vor. Er schlug vor, seine selbstprogrammierte Bibliothek in die Standardbibliothek zu integrieren. Dies sollte vorerst diskutiert werden.

125 125 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 4 Neben der Diskussion beteiligte er sich weiterhin an technischen Diskussionen und behob Fehler.

126 126 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 4 Neben der Diskussion beteiligte er sich weiterhin an technischen Diskussionen und behob Fehler.

127 127 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 4 Neben der Diskussion beteiligte er sich weiterhin an technischen Diskussionen und behob Fehler. Die behobenen Fehler dienten zum Ebnen der Integration seiner Bibliothek.

128 128 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 4 Neben der Diskussion beteiligte er sich weiterhin an technischen Diskussionen und behob Fehler. Die behobenen Fehler dienten zum Ebnen der Integration seiner Bibliothek. Obwohl nicht alle zustimmten, erklärte er die Integrierung als akzeptiert.

129 129 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 4 Neben der Diskussion beteiligte er sich weiterhin an technischen Diskussionen und behob Fehler. Die behobenen Fehler dienten zum Ebnen der Integration seiner Bibliothek. Obwohl nicht alle zustimmten, erklärte er die Integrierung als akzeptiert. Er konnte nun sein Vorhaben durchführen.

130 130 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 4 Neben der Diskussion beteiligte er sich weiterhin an technischen Diskussionen und behob Fehler. Die behobenen Fehler dienten zum Ebnen der Integration seiner Bibliothek. Obwohl nicht alle zustimmten, erklärte er die Integrierung als akzeptiert. Er konnte nun sein Vorhaben durchführen.

131 131 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Einfluss

132 132 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Einfluss

133 133 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Einfluss

134 134 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Einfluss

135 135 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Einfluss Was hat den zunehmenden Einfluss getrieben?

136 136 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Geschenke als Mittel zum Zweck

137 137 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Geschenke als Mittel zum Zweck Jeder Beitrag kann als Geschenk an die Gemeinschaft gesehen werden.

138 138 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Geschenke als Mittel zum Zweck Jeder Beitrag kann als Geschenk an die Gemeinschaft gesehen werden. Der Empfänger wird dem Schenkenden etwas schuldig.

139 139 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Geschenke als Mittel zum Zweck Jeder Beitrag kann als Geschenk an die Gemeinschaft gesehen werden. Der Empfänger wird dem Schenkenden etwas schuldig. Gegenleistungen kann ein höheres Ansehen oder eine höhere Machtposition sein.

140 140 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Geschenke als Mittel zum Zweck Jeder Beitrag kann als Geschenk an die Gemeinschaft gesehen werden. Der Empfänger wird dem Schenkenden etwas schuldig. Gegenleistungen kann ein höheres Ansehen oder eine höhere Machtposition sein.  CVS Zugriff

141 141 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Geschenke als Mittel zum Zweck Jeder Beitrag kann als Geschenk an die Gemeinschaft gesehen werden. Der Empfänger wird dem Schenkenden etwas schuldig. Gegenleistungen kann ein höheres Ansehen oder eine höhere Machtposition sein.  CVS Zugriff  Authorität in Diskussionen

142 142 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Geschenke als Mittel zum Zweck Jeder Beitrag kann als Geschenk an die Gemeinschaft gesehen werden. Der Empfänger wird dem Schenkenden etwas schuldig. Gegenleistungen kann ein höheres Ansehen oder eine höhere Machtposition sein.  CVS Zugriff  Authorität in Diskussionen Geschenk muss angenommen werden.

143 143 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Geschenke als Mittel zum Zweck Jeder Beitrag kann als Geschenk an die Gemeinschaft gesehen werden. Der Empfänger wird dem Schenkenden etwas schuldig. Gegenleistungen kann ein höheres Ansehen oder eine höhere Machtposition sein.  CVS Zugriff  Authorität in Diskussionen Geschenk muss angenommen werden. Schenker muss das „Verkaufen“ lernen.

144 144 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Verkaufen

145 145 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Verkaufen Dazu müssen Normen und Werte der epistemischen Gescheinschaft gekannt werden.

146 146 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Verkaufen Dazu müssen Normen und Werte der epistemischen Gescheinschaft gekannt werden.  Was will die Gemeinschaft?

147 147 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Verkaufen Dazu müssen Normen und Werte der epistemischen Gescheinschaft gekannt werden.  Was will die Gemeinschaft? (z.B. Projektziele)

148 148 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Verkaufen Dazu müssen Normen und Werte der epistemischen Gescheinschaft gekannt werden.  Was will die Gemeinschaft? (z.B. Projektziele) Dazu muss das soziale Netz aufgedeckt werden.

149 149 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Verkaufen Dazu müssen Normen und Werte der epistemischen Gescheinschaft gekannt werden.  Was will die Gemeinschaft? (z.B. Projektziele) Dazu muss das soziale Netz aufgedeckt werden.

150 150 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Verkaufen Dazu müssen Normen und Werte der epistemischen Gescheinschaft gekannt werden.  Was will die Gemeinschaft? (z.B. Projektziele) Dazu muss das soziale Netz aufgedeckt werden.  Wer ist wofür zuständig?

151 151 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Verkaufen Dazu müssen Normen und Werte der epistemischen Gescheinschaft gekannt werden.  Was will die Gemeinschaft? (z.B. Projektziele) Dazu muss das soziale Netz aufgedeckt werden.  Wer ist wofür zuständig?  Wer muss über- zeugt werden?

152 152 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Verkaufen Dazu müssen Normen und Werte der epistemischen Gescheinschaft gekannt werden.  Was will die Gemeinschaft? (z.B. Projektziele) Dazu muss das soziale Netz aufgedeckt werden.  Wer ist wofür zuständig?  Wer muss über- zeugt werden?  Wo stehe ich?

153 153 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 1

154 154 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 1 Die Gewinnung von Einfluss geschieht in einem Lernprozess.

155 155 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 1 Die Gewinnung von Einfluss geschieht in einem Lernprozess.  ‘Lernen in der Praxis’

156 156 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 1 Die Gewinnung von Einfluss geschieht in einem Lernprozess.  ‘Lernen in der Praxis’ Die Anforderungen teilen sich in technische und soziale.

157 157 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 1 Die Gewinnung von Einfluss geschieht in einem Lernprozess.  ‘Lernen in der Praxis’ Die Anforderungen teilen sich in technische und soziale. Die technischen Anforderungen verlangen:

158 158 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 1 Die Gewinnung von Einfluss geschieht in einem Lernprozess.  ‘Lernen in der Praxis’ Die Anforderungen teilen sich in technische und soziale. Die technischen Anforderungen verlangen:  Technische Fähigkeiten und

159 159 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 1 Die Gewinnung von Einfluss geschieht in einem Lernprozess.  ‘Lernen in der Praxis’ Die Anforderungen teilen sich in technische und soziale. Die technischen Anforderungen verlangen:  Technische Fähigkeiten und  Verständnis über das bestehende Softwaresystem.

160 160 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 1 Die Gewinnung von Einfluss geschieht in einem Lernprozess.  ‘Lernen in der Praxis’ Die Anforderungen teilen sich in technische und soziale. Die technischen Anforderungen verlangen:  Technische Fähigkeiten und  Verständnis über das bestehende Softwaresystem. Daraus ergeben sich Beitragsbarrieren.

161 161 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 1 Die Gewinnung von Einfluss geschieht in einem Lernprozess.  ‘Lernen in der Praxis’ Die Anforderungen teilen sich in technische und soziale. Die technischen Anforderungen verlangen:  Technische Fähigkeiten und  Verständnis über das bestehende Softwaresystem. Daraus ergeben sich Beitragsbarrieren. Diese äußern sich in der Spezialisierung der Neulinge.

162 162 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 2 Die sozialen Anforderungen verlangen:

163 163 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 2 Die sozialen Anforderungen verlangen:  Das Anpassen an die Vorstellungen und Ziele der Gemeinschaft und

164 164 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 2 Die sozialen Anforderungen verlangen:  Das Anpassen an die Vorstellungen und Ziele der Gemeinschaft und  Das Aufdecken der Beziehung in der Gemeinschaft.

165 165 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 2 Die sozialen Anforderungen verlangen:  Das Anpassen an die Vorstellungen und Ziele der Gemeinschaft und  Das Aufdecken der Beziehung in der Gemeinschaft. Dazu hilft das Verständnis der Gemeinschaft als epistemische (ergebnisorientierte) Gemeinschaft.

166 166 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 2 Die sozialen Anforderungen verlangen:  Das Anpassen an die Vorstellungen und Ziele der Gemeinschaft und  Das Aufdecken der Beziehung in der Gemeinschaft. Dazu hilft das Verständnis der Gemeinschaft als epistemische (ergebnisorientierte) Gemeinschaft. Durch Geschenke können Abhängigkeiten geschaffen werden.

167 167 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 2 Die sozialen Anforderungen verlangen:  Das Anpassen an die Vorstellungen und Ziele der Gemeinschaft und  Das Aufdecken der Beziehung in der Gemeinschaft. Dazu hilft das Verständnis der Gemeinschaft als epistemische (ergebnisorientierte) Gemeinschaft. Durch Geschenke können Abhängigkeiten geschaffen werden. Damit wird Einfluss gewonnen.

168 168 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 2 Die sozialen Anforderungen verlangen:  Das Anpassen an die Vorstellungen und Ziele der Gemeinschaft und  Das Aufdecken der Beziehung in der Gemeinschaft. Dazu hilft das Verständnis der Gemeinschaft als epistemische (ergebnisorientierte) Gemeinschaft. Durch Geschenke können Abhängigkeiten geschaffen werden. Damit wird Einfluss gewonnen. Es muss gelernt werden, die Geschenke zu “verkaufen”.

169 169 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Danke!

170 170 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Seminar „Komponenten“ Einfluss gewinnen Nicolai Kamenzky Freie Universität Berlin, Institut für Informatik http://www.inf.fu-berlin.de/inst/ag-se/ http://www.inf.fu-berlin.de/inst/ag-se/ Worum geht es? Das Freenet Projekt Das Python Projekt Zusammenfassung

171 171 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Worum geht es? Teilnahme an einem Open Source Software (OSS) Projekt Ausgangspunkt: Interesse an der Mitwirkung Ziel: Mitglied der Gemeinschaft mit gewünschtem Einfluss Gewünschter Einfluss? Betrachtungswinkel:  Wunsch zur Mitgestaltung der Software Einbau von Features Gestaltung der Anforderungen an die Software  Ein werdender Entwickler

172 172 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Motivation zur Betrachtung der Thematik Für das Projekt:  Mangel an Arbeitskraft.  Erfolg steht im Zusammenhang mit der Mitgliederzahl. Für das werdende Mitglied:  Ziel: Einfluss persönlicher Anforderungen an die Software.  Die OSS Gemeinschaft lässt nicht jeden an das CVS.  Beweis der „Richtige“ zu sein, wird verlangt.  Aber wie?  Dazu ist ein Lernprozess nötig.  Daran scheitern viele!

173 173 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Definitionen Listenteilnehmer  Benutzer der Software  Teilnehmer in allgemeinen Diskussionen Entwickler  Zur Entwicklung des OSS Projektes beitragende Mitglieder Neulinge  An der Entwicklung interessierte Personen Mit dem Erhalt der CVS Schreibrechte wird ein Neuling zum Einsteiger. Einsteiger  Neu in die Entwicklergruppe aufgenommene Mitglieder

174 174 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling verlangt? Die Art der entwickelten Software verlangt Fachwissen. Je nach Teilbereich der Software braucht man z.B.:  Kenntnis einer bestimmen Programmiersprache  Mehr oder weniger Mathematikkenntnisse ... Einarbeitung in die bestehende Software nötig. Dies sind die technischen Anforderungen.

175 175 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Freenet Projekt P2P-System  hochskalierbar, anonym, dezentralisiert Im Jahre 1999 von Ian Clarke gegründet. Ausgangspunkt waren seine theoretischen Überlegungen. Von Krogh, Spaeth und Lakhani haben das Projekt in seinem ersten Jahr (2000) studiert.

176 176 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Spezialisierung Projekt wurde in Module gegliedert. Welche Module wurden bearbeitet? Modul 3: Kryptographie Modul 7: Clients (GUI) Modul 9: Build & Install

177 177 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Gründe zur Spezialisierung Schwierigkeitsgrad des Änderns oder Entwickelns eines Moduls  Das Kryptographiemodul ist schwer. Wahlfreiheit der verwendeten Programmiersprache  Die Installation kann in versch. Sprachen geschrieben sein. Schwierigkeitsgrad der Integrierung des Moduls in die Softwarearchitektur  Das Interface zwischen dem Build & Install Modul und dem Rest des Systems ist klar definiert. Außmaß der Zusammenarbeit oder Unabhängigkeit der Module  Funktioniert die Kryptographie nicht, funktioniert das ganze System nicht. Dies sind Beitragsbarrieren.

178 178 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Beitragsbarrieren Der Hinderungsgrad einer Beitragsbarriere hängt von den technischen Fähigkeiten der Person ab. Die technischen Fähigkeiten können wiederum vom Grad des Verständnisses vom Softwaresystem abhängen. Der Neuling muss sich schrittweise einarbeiten.  Beobachten der technischen Diskussionen  Teilnahme an den technischen Diskussionen  Fehlerbehebung in der Software Dabei sinken für ihn die Beitragsbarrieren.

179 179 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Lernen in der Praxis Diese Vorgehensweise ist ein ‘Lernen in der Praxis’. Vergleichbar mit Lernprozess eines Azubis. Im Unterschied werden Neulinge nicht unterrichtet. Selbstständige Einarbeitung nötig. Währenddessen sind sie Randmitglieder. Sie streben eine Vollmitgliedschaft an.  Mitglied der Entwicklergemeinschaft  Verständnis des kompletten Softwaresystems  Beitrag zu wichtigen Diskussionen über das Projekt Person kann auch Randmitglied bleiben wollen.

180 180 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Was wird vom Neuling noch verlangt? Die Mitglieder eines OSS Projektes bilden eine soziale Gemeinschaft. Die Arbeit beruht auf Gegenseitigkeit. Die Arbeit sollte recht reibungslos funktionieren. Deshalb sollten gemeinsame Vorstellungen und Ziele vertreten werden. (Dies ist auch der Fall.) Der Neuling muss sich diesen anpassen. Dies sind die sozialen Anforderungen.

181 181 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Die epistemische Gemeinschaft Die OSS Gemeinschaft wird als epistemische (ergebnis- orientierte) Gemeinschaft verstanden. Primäre Motivation: Erfüllung des persönlichen Anspruchs der einzelnen Mitglieder an die Software. Eine epistemische Gemeinschaft hat folgende Eigenschaften:  Gemeinsame Normen und Werte  Gemeinsame Vorstellungen über das Vorgehen  Gemeinsame Bewertungsmaßstäbe  Gemeinsame Projektziele Erfüllen die Mitglieder die Eigenschaften weitgehend, funktioniert die Zusammenarbeit reibungsloser.

182 182 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Das Python Projekt Programmiersprache für viele Plattformen  Interpretiert, objekt-orientiert  Enfach zu erlernen und zu lesen. Ab 1990 von Guido v. Rossum entwickelt. Im Jahre 2000 unter die GPL gestellt. Nicolas Ducheneaut hat die Projektentwicklung im Jahre 2002 analysiert.

183 183 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Offengelegte Anforderungen auf der Webseite Um mit dieser großen und verstreuten Gruppe zu arbeiten, musst du lernen, wer die richtige Ansprechperson ist, wie du andere Entwickler vom Nutzen deiner Quellcodeänderung überzeugst, wie du hilfreiche Kritik lieferst und wie du Kritik annehmen musst. Wenn die Python Entwicklergruppe weiß wer du bist, entweder durch die Diskussionen auf der Mailingliste, wegen der Lieferungen von Quellcode oder durch andere Interaktionen, darfst du eine CVS Zugriffserlaubnis erfragen.

184 184 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Der OSS Project Browser Um den Grad des Einflusses einer Person zu visualisieren, hat Ducheneaut ein Programm entwickelt. Es stellt ein Netz aus Beziehungen dar.

185 185 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 1 Er beobachtete die Mailingliste.  Absorption der Normen und Werte der Gemeinschaft. Erste Nachricht im Beobachtungszeitraum betraf einen technischen Belang.  So wurde er für die Gemeinschaft sichtbar.

186 186 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 2 Durch seine Arbeit mit Python fand er zunehmend Fehler. Er berichtete sie. Er fügte meist auch Patches als Bugfix bei. Er bekam den Ruf ein guter Bugfixer zu sein. Ihm wurde der CVS Zugriff gewährt.

187 187 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 3 Er nahm nun erste, kleine Änderungen an der Softwarearchitektur vor. Er schlug vor, seine selbstprogrammierte Bibliothek in die Standardbibliothek zu integrieren. Dies sollte vorerst diskutiert werden.

188 188 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Karriere Teil 4 Neben der Diskussion beteiligte er sich weiterhin an technischen Diskussionen und behob Fehler. Die behobenen Fehler dienten zum Ebnen der Integration seiner Bibliothek. Obwohl nicht alle zustimmten, erklärte er die Integrierung als akzeptiert. Er konnte nun sein Vorhaben durchführen.

189 189 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Freds Einfluss Was hat den zunehmenden Einfluss getrieben?

190 190 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Geschenke als Mittel zum Zweck Jeder Beitrag kann als Geschenk an die Gemeinschaft gesehen werden. Der Empfänger wird dem Schenkenden etwas schuldig. Gegenleistungen kann ein höheres Ansehen oder eine höhere Machtposition sein.  CVS Zugriff  Authorität in Diskussionen Geschenk muss angenommen werden. Schenker muss das „Verkaufen“ lernen.

191 191 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Verkaufen Dazu müssen Normen und Werte der epistemischen Gescheinschaft gekannt werden.  Was will die Gemeinschaft? (z.B. Projektziele) Dazu muss das soziale Netz aufgedeckt werden.  Wer ist wofür zuständig?  Wer muss über- zeugt werden?  Wo stehe ich?

192 192 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 1 Die Gewinnung von Einfluss geschieht in einem Lernprozess.  ‘Lernen in der Praxis’ Die Anforderungen teilen sich in technische und soziale. Die technischen Anforderungen verlangen:  Technische Fähigkeiten und  Verständnis über das bestehende Softwaresystem. Daraus ergeben sich Beitragsbarrieren. Diese äußern sich in der Spezialisierung der Neulinge.

193 193 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Zusammenfassung Teil 2 Die sozialen Anforderungen verlangen:  Das Anpassen an die Vorstellungen und Ziele der Gemeinschaft und  Das Aufdecken der Beziehung in der Gemeinschaft. Dazu hilft das Verständnis der Gemeinschaft als epistemische (ergebnisorientierte) Gemeinschaft. Durch Geschenke können Abhängigkeiten geschaffen werden. Damit wird Einfluss gewonnen. Es muss gelernt werden, die Geschenke zu “verkaufen”.

194 194 Nicolai Kamenzky, kamenzky@inf.fu-berlin.de Danke!


Herunterladen ppt "1 Nicolai Kamenzky, Seminar „Komponenten“ Einfluss gewinnen Nicolai Kamenzky Freie Universität Berlin, Institut für Informatik."

Ähnliche Präsentationen


Google-Anzeigen