Beim Betrieb eines freien Software-Projekts werden Sie nicht täglich über derart schwerwiegende philosophische Themen reden müssen. Kein Programmierer wird darauf bestehen, dass jeder andere im Projekt die gleichen Ansichten vertritt wie er selbst (und wer es tut, wird ganz schnell feststellen, dass er sich an keinem Projekt beteiligen kann). Sie sollten sich aber darüber im Klaren sein, dass die Kontroverse "frei" kontra "Open Source" existiert, teils um Aussagen zu vermeiden, die von manchen Teilnehmern als feindlich aufgefasst werden könnten, teils, da ein Verständnis über die Motivationen der Entwickler der beste — in gewissem Sinne der einzige — Weg ist, ein Projekt zu leiten.
Freie Software ist eine Kultur, die man sich aussucht. Um darin erfolgreich wirken zu können, muss man verstehen, warum Leute überhaupt die Wahl treffen, sich daran zu beteiligen. Sie zu zwingen funktioniert nicht. Wenn Leute in einem Projekt unglücklich sind, gehen sie einfach zu einem anderen. Freie Software ist selbst unter internationalen Gemeinschaften darin bemerkenswert, nur eine geringe Investition zu erfordern. Die meisten Beteiligten sind einander noch nie wirklich von Angesicht zu Angesicht begegnet. Die Fäden, die Menschen für gewöhnlich verbindet, um eine beständige Gruppe zu formen, sind auf einen winzigen Kanal reduziert: das geschriebene Wort, übertragen durch elektrische Leitungen. Aus diesem Grund kann es lange dauern, bis sich eine geschlossene, engagierte Gruppe bildet. Umgekehrt kann eine Gruppe schon während der ersten fünf Minuten ihrer Begegnung mit einem potentiellen Teilnehmer sein Interesse sehr leicht verspielen. Wenn ein Projekt keinen guten ersten Eindruck macht, mögen Neulinge lange abwarten, bis sie ihm eine zweite Chance geben.
Die Vergänglichkeit der Beziehungen, bzw. ihre potenzielle Vergänglichkeit, ist das vielleicht größte Problem, dem ein neues Projekt sich stellen muss. Was soll all diese Menschen dazu bewegen, lange genug zusammen zu bleiben, um etwas Nützliches zu produzieren? Die Antwort auf diese Frage ist komplex genug, um sie zum Thema dieses Buchs zu machen. Müsste man sie jedoch in einem Satz zusammenfassen, wäre es folgender:
Menschen sollten spüren, dass ihre Verbindung zu einem Projekt und ihr Einfluss darauf proportional zu ihrer Beteiligung ist.
Kein Entwickler oder potentieller Entwickler sollte sich jemals aus nicht-technischen Gründen herabgesetzt oder diskriminiert fühlen [15]. Projekte mit Unterstützung durch Firmen müssen in dieser Hinsicht ganz besonders vorsichtig sein. Der Abschnitt Kapitel 5, Geld behandelt dieses Thema im Detail. Keine Unterstützung durch eine Firma zu haben bedeutet natürlich nicht, dass man sich um nichts Sorgen machen muss. Geld ist nur einer von vielen Faktoren, die den Erfolg eines Projekts beeinflussen können. Es sind ebenso die Fragen zu klären, welche Sprache, welche Lizenz und welche Art der Entwicklung man wählen sollte, welche Infrastrukturen man aufbauen sollte, wie man die Gründung des Projekts am besten bekanntgeben sollte und vieles mehr. Wie man ein Projekt richtig auf die Beine stellt ist Thema des nächsten Kapitels.
[15] Es kann Fälle geben, in denen Sie einige Entwickler aufgrund ihres Verhaltens, nicht in Bezug auf deren technische Mitwirkung, diskriminieren, welches das Potential hat, das Projekt zu beschädigen. Das ist vernünftig: Deren Verhalten ist relevant, weil es langfristig einen negativen Effekt auf das Projekt haben wird. Die Vielfalt der menschlichen Kultur macht diese aus, ich kann keine Einzelfallregel für alle diese Fälle nennen, außer, dass Sie versuchen sollten, alle potentiellen Teilnehmer willkommen zu heißen und, wenn Sie diskriminieren müssen, Sie dies ausschließlich auf Grundlage aktuellen Verhaltens tun, nicht auf Grundlage der Gruppenzugehörigkeit des Teilnehmers oder der Identität der Gruppe.