Seien Sie hinsichtlich der Motive ihrer Organisation so offen, wie Sie es können, ohne hierbei Geschäftsgeheimnisse offenzulegen. Wenn Sie in Ihrem Projekt eine bestimmte Funktion haben wollen, sagen wir, weil Ihre Kunden danach schreien, sprechen Sie auf den Mailinglisten offen darüber. Wenn die Kunden anonym bleiben wollen, was manchmal vorkommt, fragen Sie wenigstens, ob Sie diese als anonyme Beispiele anführen dürfen. Je mehr die öffentliche Entwicklergemeinschaft darüber weiß, warum Sie etwas wollen, desto eher wird diese Ihre Vorschlage akzeptieren.
Das widerspricht dem Instinkt – einfach anzueignen, aber schwer loszuwerden –, dass Wissen gleich Macht ist und dass je mehr anderen ihre Ziele bekannt sind, je mehr Kontrolle diese über Sie haben. Der Instinkt wäre hier aber falsch. Indem Sie sich öffentlich für eine Funktion (oder ein Bugfix, oder was auch immer) aussprechen, haben Sie ja schon Ihre Karten auf den Tisch gelegt. Die einzige Frage ist, ob Sie die Gemeinschaft überzeugen können, Ihr Ziel mit Ihnen zu teilen. Wenn Sie einfach sagen, dass Sie die Funktion haben wollen aber keine konkreten Gründe dafür nennen wollen, stehen Sie auf schwachem Boden und Leute werden anfangen, verborgene Absichten zu vermuten. Aber auch nur ein paar echte Szenarien zu nennen, die aufzeigen, warum die vorgeschlagene Funktion wichtig ist, kann sich dramatisch auf die Debatte auswirken.
Um den Grund dafür zu erkennen, sollten Sie die Alternative bedenken. All zu oft sind Debatten über neue Funktionen oder Richtungen langwierig und ermüdend. Die Argumente, welche angebracht werden, reduzieren sich meistens auf "Ich persönlich will X", oder das immer wieder beliebte "Meine langjährigen Erfahrung als Software-Entwickler hat gezeigt, dass X für Nutzer äußerst wichtig ist / eine nutzlose Krause ist, die keinen zufrieden stellen wird". Solche Debatten werden dementsprechend durch Mangel an Daten über echte Nutzung weder verkürzt noch verlängert, sondern driften immer weiter von der Praxis ab. Ohne irgend eine ausgleichende Kraft wird das Endergebnis eher von dem Wortgewandtesten, dem Hartnäckigsten oder dem Ranghöchsten bestimmt.
Ihre Position als Organisation mit reichlich Kundendaten ermöglicht Ihnen genau solch eine ausgleichende Kraft bereitzustellen. Sie können ein Kanal für Informationen sein, die sonst keine Möglichkeit hätten, zu der Gemeinschaft zu gelangen. Sie müssen sich nicht dafür schämen, dass diese Informationen Ihre Wünsche untermauern. Die meisten Entwickler haben für sich keine breite Erfahrung über die Nutzung Ihrer Software. Jeder Entwickler benutzt die Software auf seine eigene Art; über das Nutzungsverhalten anderer spekuliert er lediglich und verlässt sich auf seine Intuition. Tief im Inneren ist ihm das auch bewusst. Durch glaubwürdige Daten einer nicht unwesentlichen Anzahl an Nutzern geben Sie der Entwicklergemeinschaft etwas wie Sauerstoff. So lange Sie es richtig auslegen, wird sie es mit Begeisterung annehmen und der Wind wird zu Ihrem Gunsten wehen.
Der Schlüssel ist natürlich, es richtig zu präsentieren. Es reicht auf keinen Fall aus, nur weil Sie mit einer Menge Nutzern zu tun haben und weil diese eine gegebene Funktion brauchen (oder meinen zu brauchen), darauf zu bestehen, Ihre Lösung zu implementieren. Statt dessen sollten sich Ihre ersten Nachrichten eher auf das gegebene Problem konzentrieren, als auf eine bestimmte Lösung. Beschreiben Sie sehr ausführlich die Erfahrungen Ihrer Kunden, bieten Sie die Ihnen bestmögliche Auswertung, sowie möglichst viele Lösungsansätze. Wenn Leute zu spekulieren beginnen, wie effektiv die verschiedenen Lösungen sind, können Sie mit Ihren Daten die verschiedenen Antworten untermauern oder entkräften. Sie werden vielleicht die ganze Zeit eine bestimmte Lösung im Hinterkopf haben, heben Sie es am Anfang aber nicht hervor. Das ist keine Täuschung, sondern das übliche Verhalten eines ehrlichen Vermittlers. Schließlich ist Ihr wahres Ziel die Lösung des Problems; eine Lösung ist lediglich das Mittel zum Zweck. Wenn Ihre bevorzugte Lösung wirklich die überlegene ist, werden andere Entwickler das irgendwann auch erkennen – und Sie von sich aus unterstützen, was viel besser ist, als die Implementierung durch Einschüchterung zu erzwingen. (Es besteht natürlich auch die Möglichkeit, dass jemand anderem eine bessere Lösung einfällt als Ihnen).
Das soll nicht heißen, dass Sie sich niemals zugunsten einer bestimmten Lösung äußern können. Sie müssen aber Geduld haben, damit die Analyse, die Sie bereits intern gemacht haben, auf dem öffentlichen Verteilern wiederholt wird. Schreiben Sie nicht etwas wie "Ja, wir haben das alles hier schon gehabt, aber das funktioniert so nicht und zwar aus diesen Gründen... Wenn man der Sache auf den Grund geht, dann ist die einzige Lösung..." Das Problem ist weniger der arrogante Ton, als vielmehr der Eindruck, dass Sie bereits eine unbestimmte (aber vermutlich große) Menge analytischer Ressourcen dem Problem hinter verschlossenen Türen gewidmet haben. Es lässt die Sache so erscheinen, als ob Anstrengungen unterwegs gewesen sind, und Entscheidungen vielleicht getroffen wurden, ohne die Einweihung der Öffentlichkeit, und das führt unweigerlich zu Verbitterung.
Sie wissen natürlich, wieviel Mühe Sie dem Problem intern gewidmet haben, und dieses Wissen ist in gewisser Hinsicht ein Nachteil. Ihre Entwickler haben dadurch eine etwas andere Einstellung als alle anderen auf den Mailinglisten, wodurch ihre Fähigkeit eingeschränkt wird, die Dinge aus der Sicht derjenigen zu sehen, die noch nicht über das Problem nachgedacht haben. Je früher Sie alle anderen dazu bringen können, ihre Sicht einzunehmen, desto geringer werden die resultierende Auswirkungen sein. Diese Logik gilt nicht nur für einzelne technische Situationen, sondern auch für das breitere Mandat Ihre Ziele so klar wie möglich darzulegen. Das Unbekannte verursacht immer mehr Unruhe als das Bekannte. Wenn Menschen verstehen, warum Sie etwas wollen, werden sie sich im Gespräch mit ihnen wohl fühlen, selbst wenn sie anderer Meinung sind. Wenn sie nicht herausbekommen, was Sie bewegt, werden sie zumindest Zeitweise vom Schlimmsten ausgehen.
Sie werden natürlich nicht alles veröffentlichen können und man wird es auch nicht von Ihnen erwarten. Alle Organisationen haben Geheimnisse; vielleicht haben profitorientierte Organisationen mehr davon, aber gemeinnützige haben sie auch. Wenn Sie einen bestimmten Kurs verfechten müssen, aber nichts über Ihre Gründe offenbaren können, dann bieten Sie einfach die Ihnen mit dieser Behinderung bestmöglichen Argumente. Finden Sie sich mit der Tatsache ab, dass Sie vielleicht nicht den gewünschten Grad an Einfluss bei der Diskussion haben. Das ist einer der Kompromisse die Sie eingehen, wenn die Entwicklergemeinschaft nicht auf Ihrer Gehaltsliste steht.