Ein Bereich, in dem Open-Source-Projekte sich historisch von proprietären Projekten differenziert haben, ist die Planung neuer Versionen. Proprietäre Projekte haben gewöhnlich strengere Fristen. Manchmal weil einem Kunden zu einem bestimmten Datum ein Upgrade versprochen wurde, da die neue Version mit einer anderen Absicht aus Marketing-Gründen koordiniert werden muss, oder weil die Risikokapitalgeber die in die ganze Sache investiert haben, Ergebnisse sehen müssen, bevor sie weitere Finanzierungsmittel hineinstecken. Freie Software-Projekte hingegen waren bis zuletzt meistens durch Amateurhaftigkeit im wörtlichsten Sinne motiviert: Sie wurden aus Liebe geschrieben. Keiner hatte ein Drang, etwas zu veröffentlichen, bevor alle Funktionen fertig waren, und warum sollten sie auch? Es war ja nicht so, dass hier der Arbeitsplatz von jemandem auf den Spiel stand.

Heutzutage werden viele Open-Source-Projekte durch Firmen finanziert, und werden entsprechen mehr und mehr durch fristbewusste Unternehmenskulturen beeinflusst. Das mag in vielerlei Hinsicht etwas Gutes sein, kann aber auch Konflikte verursachen zwischen den Prioritäten der Entwickler, die bezahlt werden, von denen der Entwickler, die ihre Zeit freiwillig investieren. Diese Konflikte kommen oft bei der Frage auf, wann und wie die neuen Versionen geplant werden. Die angestellten Entwickler, die unter Druck stehen, werden natürlich einfach irgendein Datum wählen wollen, an dem die Veröffentlichung stattfinden soll, und alle anderen Aktivitäten entsprechend einordnen. Die freiwilligen Entwickler können jedoch andere Pläne haben – vieleicht Funktionen, die sie fertig stellen wollen, oder Tests, die sie gemacht haben wollen – worauf ihrer Meinung nach die Veröffentlichung warten soll.

Es gibt keine allgemeine Lösung für dieses Problem, außer natürlich zu diskutieren und Kompromisse zu schließen. Sie können jedoch den Grad und die Menge an Reibung die verursacht wird minimieren, indem Sie die Existenz der vorgeschlagenen Version von dem Datum entkoppeln, an dem sie veröffentlicht werden soll. Das heißt, versuchen Sie die Diskussion in Richtung des Themas zu lenken, welche Versionen das Projekt in der nächsten bis mittelfristigen Zeit machen wird, und welche Funktionen sie haben werden, zunächst ohne über Termine zu sprechen, abgesehen von groben Schätzungen mit einer Menge Spielraum. ^[52] Indem Sie frühzeitig den Funktionsumfang festlegen, reduzieren Sie die Komplexität der Diskussion, die sich um irgend eine bestimmte Version dreht, und verbessern dadurch die Berechenbarkeit. Das verursacht auch eine Art träger Voreinstellung, auf Leute, die vorschlagen die Definition einer Version mit neuen Funktionen oder andere Komplikationen zu erweitern. Wenn der Inhalt der Version relativ gut definiert ist, obliegt die Rechtfertigungspflicht für Erweiterungen dem Vorschlagenden, auch wenn das Datum der Version noch nicht festgelegt wurde.

In seiner mehrbändigen Thomas-Jefferson-Biographie, Jefferson and His Time, erzählt Dumas Malone die Geschichte, wie Jefferson das erste Treffen handhabte, das abgehalten wurde, um über die Organization der zukunftigen Universität von Virginia zu entscheiden. Die Universität war von Anfang an die Idee von Jefferson gewesen, aber (wie es überall der Fall ist, nicht nur in Open-Source-Projekten) waren sehr schnell viele andere Parteien an Bord, jede mit eigenen Interessen und Anliegen. Als sie sich zu diesem ersten Treffen versammelten, um alles auszuarbeiten, erschien Jefferson mit minuziös vorbereiteten Bauplänen, detaillierten Budgets für die Konstruktion und den Betrieb, einem Lehrplanentwurf, und den Namen der einzelnen Fakultäten die er aus Europa importieren wollte. Kein anderer im Raum war nur annähernd so gut vorbereitet; die Gruppe musste im wesentlichen vor der Vision von Jefferson kapitulieren und die Universität wurde letztlich mehr oder weniger entsprechend seinen Plänen gegründet. Die Tatsachen, dass die Konstruktion weit über sein Budget ging, und viele seiner Ideen aus verschieden Gründen am Ende nicht funktionierten, waren Dinge, von denen Jefferson wahrscheinlich anfangs genau wusste, dass sie passieren würden. Sein Vorhaben war strategisch: Bei der Versammlung mit etwas derart Stichhaltigem aufzutauchen, dass jeder ander in die Rolle verfallen müsste, lediglich Änderungen daran vorzuschlagen, damit die allgemeine Gestalt, und dadurch der Terminplan des Projekts, ungefähr so bliebe, wie er es wollte.

Im Falle eines freien Software-Projekts, gibt es kein einzelnes "Treffen", sondern stattdessen eine Reihe kleiner Vorschläge die meistens durch den Bugtracker gemacht werden. Wenn Sie aber von Anfang an etwas Ansehen im Projekt haben, und anfangen verschiedene Funktionen, Verbesserungen, und Fehler für bestimmte Versionen im Bugtracker festzulegen, entsprechend irgend einem erklärten Gesamtplan, werden die Leute meistens mitmachen. Wenn Sie erst alles mehr oder weniger so ausgelegt haben, wie Sie es wollen, werden die Unterhaltungen über echte Termine für neue Versionen sehr viel glatter verlaufen.

Es ist natürlich äußerst wichtig, dass Sie niemals irgend eine einzelne Entscheidung als in Stein gemeißelt präsentieren. Zeigen Sie in den Kommentaren anlässlich der Zuordnung von Bugs zu bestimmten Versionen wenn möglich stets Bereitschaft zu Diskussionen, Meinungsverschiedenheiten und die allgemeine Bereitschaft, überredet zu werden. Üben Sie niemals Kontrolle alleine um ihrer Ausübung willen: Je mehr andere sich an der Planung einer neuen Version beteiligen (siehe „Teilen sie sowohl Verwaltungsaufgaben als auch technische Aufgaben“ im Kapitel Kapitel 8, Leitung von Freiwilligen), desto leichter wird es sein sie zu überreden, Ihre Prioritäten bei Angelegenheiten zu teilen, die Ihnen wirklich wichtig sind.

Die andere Möglichkeit, Spannungen bei der Planung neuer Versionen des Projekts zu veringern ist, relativ häufig zu veröffentlichen. Wenn zwischen den Veröffentlichungen eine lange Zeit liegt, wird die Bedeutung von jeder einzenen in den Köpfen allern vergrößert; die Leute sind um so mehr betrübt, wenn ihr Code es nicht hinein schafft, weil sie wissen wie lange es dauern könnte, bis die nächste Gelegenheit kommt. Abhängig von der Komplexität des Ablaufs bei einer neuen Version und der Natur Ihres Projekts, liegt die richtige Zeit zwischen den einzelnen Veröffentlichungen gewöhnlich irgendwo zwischen drei und sechs Monaten, obwohl in den Stabilen Zweigen Micro-Veröffentlichungen ein wenig schneller geschehen können, wenn dafür Bedarf besteht.