Andrew Gallant ist Autor und Projektbetreuer mehrerer Open-Source-Projekte und versucht, die Spannungen abzubauen, die sich kürzlich in der Open-Source-Community angesammelt haben. Die Schreie der Seele "Wie ist es, ein freier Software-Betreuer zu sein?" , "Ungrateful Open Source" und andere Beschwerden der Betreuer lösten eine Diskussion über Aggressivität, Grobheit, Undankbarkeit, emotionalen Burnout und die Schwere der selbstlosen Unterstützung für Projekte aus. Der Beitrag wurde am 19. Januar 2020 veröffentlicht. trans.

Ich möchte mich von der Tradition verabschieden, fast ausschließlich über technische Themen zu sprechen - und einige meiner persönlichen Beziehungen zu freier und Open-Source-Software (FOSS) teilen. Obwohl alle Menschen unterschiedlich sind, hoffe ich, dass der Meinungsaustausch dazu beiträgt, gegenseitiges Verständnis, Empathie und Vertrauen in unsere Gemeinschaft aufzubauen.

Bitte betrachten Sie diesen Beitrag nicht als direkte Reaktion auf die Aktionen eines anderen Betreuers. Dies ist kein Rezept für ein ideales Verhalten, sondern eine persönliche Reflexion in der Hoffnung, dass sie für andere zu einer Gelegenheit werden, über ihre eigenen Beziehungen zu Open Source nachzudenken. Es gibt keinen richtigen Weg, um ein guter Betreuer zu werden. Jeder hat seine eigene Art, damit umzugehen.

Dies ist keineswegs ein Hilferuf. Es geht um Verständnis. Ich fordere keine Veränderung in der FOSS-Wirtschaft und spreche nicht über meine geistige Gesundheit. Ich spreche nicht davon, zusätzliche Betreuer zu gewinnen. Ich möchte nur meine Geschichte teilen und versuchen, das Einfühlungsvermögen in der FOSS-Community zu stärken.

Zielgruppe : Alle an Open Source Beteiligten.

Inhalt

• Die Geschichte
  
• Verdammte Gefühle
  
• Eitriges Negativ
  
• Arbeite durch Kraft
  
• Unhöflichkeit
  
• Behörde
  
• Mehr zur Kompetenz
  
• Vertrauen
  
• Besser als es scheint
  
• Fazit

Die Geschichte

Mein erstes Open-Source-Projekt kam vor fast 16 Jahren heraus - ein Schwarzes Brett in PHP. Zu dieser Zeit schufen fast alle solche Dinge, und so lernte ich das Programmieren. Das Projekt begann ursprünglich als Schulsystem für Diskussionen (zu dieser Zeit arbeiteten die Schulen überhaupt nicht mit dem Internet, außer für das Hosten beschissener Websites). Dann stieß ich zuerst auf die Schwierigkeit der Schätzung. Das Projekt dauerte viel länger als ein Semester und entwickelte sich allmählich zu einem Hobby, das über den Rahmen des Schulprojekts hinausging.

Persönlich habe ich es immer geliebt, nur zum Spaß zu programmieren. Ich mag alle Phasen: zuerst ein Thema ausloten, Machbarkeit bestimmen, einen ersten Plan entwickeln, obsessiv programmieren und sogar darüber nachdenken, ich mag jede Minute von allem.

Um Spaß am Programmieren zu haben, muss ich die Ergebnisse meiner Arbeit nicht teilen. Open Source wurde jedoch schnell zu einem natürlichen Bestandteil meines Entwicklungsprozesses, der 16 Jahre in der einen oder anderen Form bestand. Tatsächlich gefällt mir am besten, wenn der Code es jemandem ermöglicht, sein Problem effizienter zu lösen. Je besser mein Code ist, desto angenehmer. In der Regel ist es mir egal, wer auf der anderen Seite nur ein Hacker ist, der seine Neugier befriedigt, oder ein riesiges Unternehmen, das etwas Interessantes in einem unglaublichen Umfang tut.

Meine FOSS-Geschichte ging weiter mit mehreren Veröffentlichungen meines Bulletin Boards und von wtcSQLite , einem einfachen Klon von phpMyAdmin , aber für SQLite.

Als ich um 2009 von Windows zu Linux wechselte, startete ich noch mehr Projekte, aber in Python und X11. Darunter befinden sich PyTyle zum Fixieren von Frames im Multi-Window-Manager und openbox-multihead , meine Implementierung der Multi-Monitor-Unterstützung in Openbox . Diese Projekte, zusammen mit einigen Recherchen von Go, haben mich veranlasst, den Fenstermanager auf Go zu erstellen, den ich immer noch verwende.

Mit der Zeit begann ich vor ungefähr sechs Jahren in Rust zu schreiben. Quickcheck wurde die erste Bibliothek, aber es folgten eine Reihe weiterer Bibliotheken: Regex , docopt.rs , rust-csv , fst , termcolor , walkdir und viele andere in den nächsten sechs Jahren.

Obwohl es sich bei den meisten meiner Rust-Projekte um Bibliotheken handelt, gibt es Befehlszeilentools wie xsv und ripgrep .

Viele meiner alten Projekte sind mittlerweile tot oder werden von anderen unterstützt, aber ich unterstütze weiterhin die meisten Rust-Projekte. Oder sie wurden durch Racks von besserer Qualität ersetzt (zum Beispiel, wie der Querbalkenkanal den Chan ersetzte).

Heute programmiere ich immer noch gerne viel, verbringe aber auch viel Zeit mit Codeüberprüfungen, dem Debuggen von Problemen mit Endbenutzern, der Beantwortung von Funktionsanfragen und anderen Dingen. Dies bedeutet ausnahmslos Interaktion, Arbeit und Kommunikation mit anderen Menschen.

Verdammte Gefühle

In meiner Jugend war ich stolz auf meine „Logik“ und „unparteiische Entscheidungsfindung“. Wie bei jeder guten Selbsttäuschung gibt es hier ein Körnchen Wahrheit. Aber im Wesentlichen bin ich persönlich ein zutiefst emotionales Wesen.

Emotionen fließen tief und können eine wirklich nützliche Quelle für interne Motivation sein. Zum Beispiel hasste ich es einige Zeit nach der Veröffentlichung von ripgrep wirklich, den Code zu berühren, der für die Anzeige der Suchergebnisse verantwortlich ist . Er war verwirrt, fehlerhaft und schwer zu wechseln. Das vollständige Umschreiben des Codes ist eine völlig logische Entscheidung, die aus rein technischen Gründen getroffen werden kann, aber ich war motiviert , dies aus Abscheu heraus zu tun. Ich mochte meine Gefühle einfach nicht . Emotionen halfen mir, die Situation zu verbessern und mir selbst zu helfen. Zum Beispiel wird die Ausgabe jetzt in einer separaten Bibliothek mit gründlichen Tests isoliert, und ich fühle mich jedes Mal viel besser, wenn ich in diesen Code gehen und etwas tun muss. Dies ist immer noch nicht meine beste Arbeit, aber es ist bereits eine große Verbesserung - zumindest aus emotionaler Sicht - im Vergleich zum vorherigen Zustand.

Emotionen sind eine lustige Sache, weil sie Sie in wirklich erstaunliche Zustände führen können. Angenommen, im vorherigen Beispiel reichen einige technische Gründe aus, um den Ausgabecode neu zu schreiben? Hier müssen Sie eine Entscheidung treffen. Aber wenn es keine Motivation gibt, werde ich es vielleicht nie wagen, umzugestalten. Und ohne Refactoring wird die Codebasis höchstwahrscheinlich stagnieren und das Programm wird anfangen zu scheitern oder eine Kombination aus beiden. Wenn Emotionen motivieren, eröffnet das Refactoring eine viel bessere Zukunft, in der Sie mehr Funktionen in die Software implementieren können, ohne die Zuverlässigkeit zu beeinträchtigen.

Emotionen haben einen Nachteil. Jeder, der eine recht populäre Software herausbrachte und unterstützte, war sicher, andere Leute zu kontaktieren. Es stellt sich heraus, dass eine andere Person einen erstaunlichen Effekt auf Ihren emotionalen Zustand haben kann. Eine positive Geste oder ein Kommentar kann Ihren Tag erhellen. Das gleiche Gefühl: Ja, das Hochladen meines Codes war so wichtig, dass es dieser Person half . Aber wie jeder Betreuer bestätigt, werden positive Kommentare fast immer von negativen überschattet.

Negative Kommentare sind nicht so schlimm. Dies ist eine natürliche Folge der Codefreigabe, wenn Sie andere Benutzer einladen, diese zu verwenden und Probleme zu melden . Wenn eine Fehlermeldung angezeigt wird, haben Sie das Gefühl, dass dieser Benutzer einen Fehler hat. Als Sie den Code geschrieben haben, waren Sie sicher, dass Sie ihn gut genug getestet haben, aber er ist immer noch falsch . Werden die Fehlerberichte niemals aufhören? Wie viel Zeit hat dieser Benutzer aufgrund eines Fehlers verschwendet? Wie lange werde ich brauchen, um alles zu reparieren? Nicht einmal das: Wie viel Zeit brauche ich, um einfach in einen Modus zu wechseln, in dem zumindest Hoffnung besteht, ihn zu beheben?

Diese Gedanken können zu Emotionen führen, die Sie untergraben. Und dies ist das wahrscheinlichste Szenario für negative Kommentare.

Eitriges Negativ

Aus Fehlerberichten habe ich schnell gelernt, negative Emotionen zu überwinden. Tatsächlich machen gut lesbare Fehlermeldungen schnell Spaß, da sie normalerweise sehr selten sind. Die meisten Fehler werden überhaupt nicht reproduziert, selbst wenn Sie eine Vorlage für das Problem mit expliziten Anforderungen für alle Parameter bereitstellen (Vorlage ausgeben). Der Absender möchte wahrscheinlich das Beste, aber die Informationen reichen einfach nicht aus, um den Fehler zu reproduzieren. Und die Aufregung beginnt hin und her, um den Fehler zu isolieren.

Für mich persönlich ist dies die schmerzhafteste Stelle. Emotionen gewinnen die Oberhand, weil ich nur an eines denken kann: Warum hat sich diese Person nicht die Zeit genommen, die Vorlage für das Problem zu lesen und auszufüllen ? Oder wenn ein Fehler aufgrund eines Fehlers eines Benutzers auftritt, der die Dokumentation nicht gelesen hat, kann ich nur denken: Ich habe mir die Zeit genommen, diesem Benutzer Software zu geben, und er kann vor dem Einreichen eines Fehlerberichts nicht einmal die README-Datei lesen.

Das ist verrückt. Emotionen sind natürlich nicht immer rational. Die Dokumentation könnte wahrscheinlich übersichtlicher sein. Oder der Benutzer hat diesen Artikel möglicherweise nicht bemerkt. Vielleicht hat er keine Erfahrung darin, FOSS-Projekte durchzuführen oder Fehlerberichte einzureichen, und vielleicht weiß er nicht, wie er bei der einfachen Reproduktion eines Fehlers helfen kann. All dies sind vernünftige Annahmen, und deshalb gebe ich mein Bestes, damit keine Emotionen überwiegen. Einfühlungsvermögen gegenüber der Person am anderen Ende des Kabels ist ebenfalls wichtig.

Angenommen, ich sage nirgendwo "Ich lade Sie ein, meinen Code zu verwenden", aber ich mache eine Menge Dinge, nur weil meine Absicht ist, dass andere meinen Code verwenden. Ich schreibe detailliertere Dokumentationen, Anwendungsbeispiele. Ich habe kontinuierliche Integrationstests eingerichtet. Gemachtes README für Anfänger. Der Link zum Projekt ist auf vielen meiner Seiten angegeben. Wenn Leute dieser Aufforderung, meinen Code zu verwenden, zustimmen oder einen offenen Bug-Tracker als Aufforderung betrachten, Fehler zu melden, sollte ich sie nicht bestrafen, wenn sie diese Nachrichten wirklich senden. Der Autor eines schlechten Fehlerberichts glaubt wahrscheinlich, dass er alles Mögliche getan hat. Und während sie aus guten Taten handeln, versuche ich wirklich, dasselbe zu beantworten.

Dies unterstreicht die Asymmetrie zwischen Benutzer und Betreuer. Die Autoren vieler Fehlerberichte können eine oder zwei Nachrichten mit mir austauschen. Für sie ist ein schlecht geschriebener Fehlerbericht nicht wirklich wichtig. Aber ich bin auf der falschen Seite, weil ich diese Szene in all meinen Projekten immer wieder abgespielt habe. Die ganze Zeit. Fast jeden Tag. Einfühlungsvermögen in einer solchen Situation aufrechtzuerhalten ist äußerst schwierig, besonders wenn Sie einen schlechten Tag haben. Was passiert manchmal.

Manchmal manifestiert sich meine Ungeduld in zu kurzen Antworten. Ich versuche mein Bestes, um in dieser Hinsicht besser zu werden. Der Prozess der Selbstverbesserung ist noch nicht abgeschlossen.

Arbeite durch Kraft

Wenn Sie der Verwalter eines beliebten Projekts oder mehrerer regulärer Repositorys sind, erhalten Sie einen nahezu kontinuierlichen Strom von Fehlerberichten und Poolanforderungen. Sie kommen täglich. Mit ihm Schritt zu halten ist fast unmöglich. Der Cache meines Gehirns ist ungewöhnlich klein, daher kann ich nicht sehr gut zwischen Projekten wechseln. Aufgrund dieses Phänomens habe ich schnell Fehlerberichte erstellt und Anfragen für die Projekte zusammengefasst, mit denen ich kürzlich gearbeitet habe. Diese Projekte sind wahrscheinlich zugänglicher oder besser auf den letzten Seiten des Gehirn-Cache angesprochen.

In anderen Projekten beginnt sich die Liste der Probleme zu häufen. Sie sehen jeden Tag eine neue Ausgabe und sagen sich: "Ja, das werde ich mir wirklich ansehen, sobald ich von der Arbeit zurück bin." Aber es kommt etwas Neues. Infolgedessen entsteht die Motivation zum Wechseln des Kontexts nur, wenn der Benutzer Sie vier Monate lang monatlich anruft - wahrscheinlich ist seine Poolanforderung wirklich wichtig.

Entschuldigung, im letzten Satz war ein bisschen Sarkasmus, aber gleichzeitig ist es wahr. Die Asymmetrie zwischen Benutzern und Betreuern ist wieder vorhanden, aber ich versuche wirklich, den Pool der Anforderungswarteschlangen zu leeren und das Projekt zu entwickeln. Ich möchte diesem Benutzer nicht nur einen Beitrag leisten, um meinen Code weiter zu verwenden, sondern auch, um ihn glücklich zu machen. In vielen Fällen reicht bereits eine Stunde aus, um die Pool-Anforderungen und alle Probleme zu klären, bei denen Maßnahmen erforderlich sind.

Aber ich verbrachte vier Monate damit, traurig zuzusehen, wie die Probleme derer schwinden, die ohne Lösung eintreten.

Für dieses Phänomen habe ich eine Methode angewendet, die ich in meinem persönlichen Leben sehr effektiv verwende: Grenzen setzen. Höflich, aber fest Grenzen setzen ist einer dieser magischen Hacks, die sich auszahlen, sobald Sie es lernen. Wenn Sie nicht wissen, wie das geht, kann ich es Ihnen kaum erklären. Wenn Sie jedoch Grenzen setzen, können Sie sich auf das konzentrieren, was Ihnen wichtig ist, nicht auf andere .

Offensichtlich muss man sich um Ausgewogenheit bemühen. Die Festlegung von Grenzen bedeutet nicht, dass Sie sich nur auf Ihre eigenen Angelegenheiten konzentrieren können. Aber die Fähigkeit, diese Mauer aufzustellen und zu sagen: "Nein, ich mache kein X, aber ich mache gerne Y" - es wirkte wirklich Wunder für mich. Mein Geheimnis ist es, Argumente vorzubringen, mit denen andere aufgrund meiner eigenen Erfahrungen und Wünsche nicht streiten können.

Was hat das mit Open Source zu tun? Für mich persönlich war der Schlüssel, eine Grenze zwischen mir selbst und all diesen Waisenproblemen bei Poolanfragen zu schaffen. Sie müssen sich irgendwie beeindrucken: „Ich verbringe meine Zeit freiwillig und es ist normal, dass ich nicht rechtzeitig antworte. Ich bin sicher, die meisten Leute werden das verstehen und vernünftig sein. "

Dies wird auch angezeigt, wenn Anforderungen für neue Funktionen besprochen werden. Manchmal mag die Anfrage für Ihr Projekt einen Sinn ergeben, aber diese Funktion bedeutet eine große Belastung für die Unterstützung. Ich habe gelernt, Grenzen zu setzen: Sie können einer Funktion nur dann „Nein“ sagen, wenn Sie keine zusätzliche Zeit für die Unterstützung aufwenden möchten. Wie es schon mehrmals passiert ist, können Sie Ihre Meinung ändern! Wenn sich der Code beispielsweise verbessert hat, wird der Zugriff für die Wartung verbessert - Sie bemerken möglicherweise einen größeren Wunsch, neue Funktionen einzuführen. Aber wenn nicht, dann gebe ich mein Bestes, um meine Grenzen zu überschreiten und lehne es ab, mich mit zusätzlicher Arbeit zu belasten, die keine Freude bereitet.

Ich möchte Schritt für Schritt Anweisungen schreiben, wie man feste Grenzen setzt und aufhört, sich wegen einer Menge Probleme schlecht zu fühlen. Dies beseitigt das Negative nicht vollständig, aber es hilft sehr.

Unhöflichkeit

Offensichtliche Trolle sind normalerweise leicht zu handhaben. Dies ist eine Gruppe von Menschen mit offensichtlichen Absichten, Sie wütend zu machen. Trolle senden in der Regel keinen Code, sodass ihren Kommentaren nicht viel Aufmerksamkeit geschenkt werden muss. Zumindest sage ich mir das im Rahmen des Abwehrmechanismus. Wenn ich einen Troll sehe, melde ich ihn normalerweise zur Unterstützung von GitHub mit anschließender Blockierung. Im Allgemeinen treffe ich mich sehr selten mit solchen Charakteren, daher scheine ich hier Glück zu haben.

Aber Unhöflichkeit nimmt viele Formen an. Meine Emotionalität setzt einen ziemlich engen Rahmen des Anstands, so dass man diese ganze Unhöflichkeit nicht in Betracht ziehen kann. Aber aus meiner Sicht ist das zumindest unhöflich.

• "Ihr Tool funktioniert nicht [für meine Nische], daher ist es defekt."
  
• "Ich werde nur eingreifen, um zu sagen, dass mir diese Funktion auch gefallen würde." (Hinweis: Es scheint, dass einige Leser das, was ich als "Grobheit" bezeichne, nicht ertragen können. Vielleicht ist dies ein zu starkes Wort, aber wenn sie in der Diskussion solche " "Add-Ons", das E-Mail-Rauschen kann nerven. Stattdessen sind Emoticons willkommen oder Sie können Ihrem speziellen Anwendungsfall einige Details hinzufügen. Vor dem Hintergrund sieht es jedoch recht klein aus, und das sehe ich hier wirklich astisch mein problem).
  
• Um darauf zu bestehen, dass die Funktion implementiert wird, müssen Sie " nur X machen".
  
• Passive Aggression, wenn Sie eine Funktionsanforderung weiterleiten.
  
• Unkonstruktives Nörgeln über Software in [hier Social Media einfügen].
  
• Variationen zum Thema „Warum erfindest du das Rad neu?“ Oder „Warum trägst du nicht stattdessen zu einem bestehenden Projekt bei?“

In vielen Fällen ist Grobheit das Ergebnis einer echten Enttäuschung des Benutzers. Wie oft haben Sie laut gemurmelt, als sich ein Instrument nicht so verhalten hat, wie Sie es möchten? Es spielt keine Rolle, dass Ihnen dieses Tool wahrscheinlich kostenlos zur Verfügung gestellt wird. Sie versuchen nur, ein Problem zu lösen, und das Tool steht Ihnen im Weg. Ich selbst habe es definitiv gespürt. Meiner Meinung nach ein ganz normales menschliches Gefühl.

Manchmal herrscht Unhöflichkeit, die sich auf verschiedene unproduktive Arten ausdrückt. Ich weiß, dass ich das selbst getan habe und natürlich auch auf der anderen Seite. Das ist für alle Beteiligten unglaublich ärgerlich.

In anderen Fällen verstehen manche Menschen ihre Grobheit nicht. Vielleicht wegen der Sprachbarriere oder weil sie einfach nicht wussten, wie sich ihre Worte auf andere auswirken würden. Ziemlich unschuldig, ändert aber nichts an meinen Gefühlen.

Der Umgang mit dieser Art von Grobheit kann sehr schwierig sein. Vielleicht stören diese Probleme niemanden, aber ich bin keiner von ihnen. Ich könnte so tun , als würde es mich nicht stören, aber ich bin mir sicher, dass dies zu einer Beleidigung von Open Source und noch mehr Enttäuschung führen wird.

Auch hier hat mir das Setzen von Grenzen geholfen. Wenn wir die Trolle wegwerfen, reagiert die überwiegende Mehrheit der Schnapper normalerweise recht gut, wenn Sie sie höflich ansprechen. Ich habe das in meinen Bug-Trackern oft gemacht, und das hat die Situation im Allgemeinen verbessert. Ich fühle mich nicht beleidigt, weil ich mich selbst beschütze, und gleichzeitig fühle ich mich besser, wenn sich die andere Person entschuldigt, was in den allermeisten Fällen der Fall ist.

Dazu reicht es aus, einfach zu sagen: "Es gefällt mir nicht, wie Sie X gesagt haben. Ich denke, es wird viel produktiver sein, wenn wir solche Einsprüche in Zukunft ablehnen."

Aber in einigen Fällen reagieren die Leute nicht sehr gut auf solche Wörter. Nach meiner Erfahrung ignorieren sie sie normalerweise. Wenn sie weiterhin unhöflich sind, kann ich dies einige Male wiederholen, da einige mehrmals etwas hören müssen, um sie zu erreichen. Zumindest weiß ich das alleine (sehr zum Missfallen meiner Frau). Wenn das immer noch nicht funktioniert und mich ihr Ton immer noch stört, höre ich auf zu interagieren. Schließen oder blockieren Sie einfach das Problem oder die Poolanforderung oder gehen Sie weiter, bis der Benutzer auf [Social Media hier einfügen] blockiert ist.

Behörde

Es war einmal ein Gespräch mit einigen engen Freunden, die ins Ausland reisten. Sie sind gerade in die USA zurückgekehrt und haben ein kleines Beispiel für einen kulturellen Schock genannt. Hauptsache?

Ich habe nie darüber nachgedacht, wie sehr Amerikaner Gewalt lieben.

Ob dies ein Merkmal der gesamten amerikanischen Kultur ist oder nur die Umwelt - wir werden nicht diskutieren. Der Punkt ist, dass einige Leute gerne darüber reden, was andere Leute tun sollten . Ich bin mit solchen Nahrungsmitteln von Menschen auf den unterschiedlichsten Ebenen der Machthierarchie aufgewachsen - und ich fühle mich wirklich angewidert dafür.

Ich bin absolut davon überzeugt, dass die meisten Menschen ein solches Verhalten nicht einmal bemerken. Einige wollen nicht in Ihr Leben kommen, sondern versuchen einfach, Ratschläge zu geben. Zumindest reagieren sie so, wenn ich auf besonders ungeheure Fälle von Zwang hinweise.

Ein bisschen zurückzutreten und das Wort "sollte" zu verwenden, ist an sich nicht unbedingt schlecht. Was sich aber wirklich ändert, ist meiner Meinung nach das Vorhandensein einer Einladung . Wenn Sie jemanden um Rat zu einem Thema gebeten haben und er etwas wie „Ja, Sie müssen X machen“ sagt, dann hört sich das nicht so schlecht an. Aber wenn eine Person ohne Einladung auftaucht, entsteht ein völlig anderes Gefühl.

:

• .
  
• [ ].
  
• .
  
• [ ].
  
• .

, - . . , , - , . , - , - , .

, , . :

• , « ?», , . FAQ .
  
• . , - , .

, . , Rust, UNLICENSE . - «» , () , . . . - , .

, . - , . . , .

, . , , , - .

, - ( ), . . . -, . - , — , , — . , -: - , .

. . , , .

. open source. , , , .

FOSS — . , . FOSS , , . , .

, . - , , , .

. , . :

• , , ?
  
• ?
  
• ?
  
• ?

, . , . , . . — , . , , .

, JSON, , . , / . .

, , . . , . , , . , .

, , . , , FOSS.

,

. : « ?» , . . , , . , ( ) .

, :

• , . , . , : «, , . ».
  
• -, .
  
• -, , , . — , .
  
• changelog, , . , , .
  
• , , . , .
  
• . , , .
  
• . , , .

, — — . . , , , . .

Fazit

FOSS, . , . , . , . , , . , . - , FOSS.

, , , , . , .

In dem Artikel habe ich viele Verhaltensweisen aufgelistet, die ich für negativ halte. Nicht jeder wird sie so negativ wahrnehmen wie ich. Das ist normal und wird erwartet . Außerdem habe ich selbst einige dieser negativen Dinge getan. Die Menschen sind nicht perfekt und wir können niemals 100% der Zeit voll reagieren. Dies sind subtile Fragen, und ich hoffe, dass wir die Situation zumindest ein wenig verbessern können.