Ein Bereich in dem Open Source Projekte sich historisch unterschieden haben, ist bei der 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 Bemühung aus marketing Gründen koordiniert werden muss, oder weil die Risikokapitalgeber wie in dem ganzen investiert haben, Ergebnisse sehen müssen, vor sie weitere Finanzierungsmittel hinein stecken. Freie Software Projekte andererseits, waren bis zuletzt meistens durch Amateurhaftigkeit im wörtlichsten Sinne motiviert: Sie wurden aus liebe geschrieben. Keiner hatte ein Drang es vor alle Funktionen fertig waren zu veröffentlichen, und warum sollten sie auch? Es war nicht so als ob die Arbeitsstelle von jemand auf den Spiel stand.

Heutzutage werden viele Open Source Projekte durch Firmen finanziert, und werden entsprechen mehr und mehr durch Fristbewusste Unternehmenskulture beeinflusst. Das mag in vielerlei Hinsicht etwas gutes sein, es kann aber auch Konflikte verursachen, zwischen den verschiedenen Prioritäten der Entwickler die bezahlt werden und solche 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 irgend ein Datum wählen wollen wann 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 Sie meinen, dass 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 Existence der vorgeschlagenen Version von dem Datum entkoppeln, an dem es 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 etwas über Termine zu sagen, außer grobe Schätzungen, mit einer menge Spielraum. Indem man früh den Funktionsumfang festlegt, 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äge Voreinstellung, auf alle die vorschlagen die Definition einer Version mit neuen Funktionen oder andere Komplikationen zu erweitern. Wenn der Inhalt der Version relativ gut definiert ist, liegt die Pflicht bei dem vorschlagenden die Erweiterung zu rechtfertigen, auch wenn das Datum der Version noch nicht festgelegt wurde.

In seiner mehrere Bänder umspannende Biographie von Thomas Jefferson, Jefferson and His Time, erzählt Dumas Malone die Geschichte, wie Jefferson das erste Treffen handhabte, welches gehalten wurde, um über die Organization der zukunftigen Universität von Verginua zu entscheiden. Die Universität war von Anfang an, die Idee von Jefforson gewesen, aber (wie es überall der Fall ist, nicht nur in Open Source Projekten) waren viele andere Parteien sehr schnell an bord geklettert, jede mit seinen eigenen Interessen und Anliegen. Als sie sich zu diesem ersten Treffen versammelten um alles auszuarbeiten, erschien Jefferson mit minuziös vorbereiteten Bauplänen, detalierten Budgets für die Konstruktion und den Betrieb, einen vorgeschlagenen Lehrplan, und die Namen der spezifischen Fakultäten die er aus Europa importieren wollte. Kein anderer in dem Raum war nur annähernd so gut vorbereitet; die Gruppe musste im wesentlichen vor der Vision von Jefferson kapitulieren, und die Universität wurde letztendlich 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 alles Sachen, 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 fallen müsste, lediglich Änderungen daran vorzuschlagen, damit die allgemeine Gestalt, und dadurch der Terninplan des Projekts, ungefähr so wäre, wie er es wollte.

Im Falle eines freien Software Projekts, gibt es kein einzelnes "Treffen", sonder statt dessen seine Reihe kleiner Vorschläge die meistens durch den Bug Tracker gemacht werden. Wenn Sie aber von Anfang an ein weinig Ansehen im Projekt haben, und anfangen verschiedene Funktionen, Verbesserungen, und Fehler für bestimmte Versionen in den Bug Tracker festzulegen, entsprechend irgend einem erklärten Gesamtplan, werden die Leute meistens mitmachen.Wenn Sie erst alles mehr oder weniger wie Sie es haben wollen ausgelegt haben, 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 gemeiselt präsentieren. Zeigen Sie in den begleitenden Kommentaren jeder Zuweisung einer Angelegenheit zu einer bestimmten Version, bereitschaft zu Diskussionen, Meinungsverschiedenheiten, und allgemeine Bereitschauf überredet zu werden wenn möglich. Ü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, die das Projekt die Spannungen bei der Planung neuer Versionen veringern kann, ist relativ oft Veröffentlichungen zu machen. Wenn zwischen den Veröffentlichungen eine lange Zeit liegt, wird die Bedeutung von jeder einzene, in den Köpfen aller, vergrößert; 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 micro Versionszweigen Veröffentlichungen ein wenig schneller geschehen können, wenn danach Bedarf besteht.