"Brauchst du dieses Feature wirklich?" und 11 weitere Learnings

Schon seit 4 Jahren gibt es den Prototype Fund! Unsere 8. Förderrunde steht in den Startlöchern und die 9. Bewerbungsrunde ist eröffnet. In den letzten Jahren hat der Prototype Fund 140 Projekte auf ihrem Weg zu einem einsatzfähigen Prototyp begleitet, und wir haben von diesen vielen Projekten eine Menge gelernt – nicht nur über die Technologie sondern auch darüber, was Teams brauchen, um während der Projektlaufzeit weder Zeit, Energie noch Motivation zu verlieren.

Weil es uns wichtig ist, dass Projekte das Beste aus ihrer Förderzeit machen können, haben wir hier 12 Erkenntnisse aufgelistet, die unserer Erfahrung nach für alle, die ein neues Projekt angehen wollen, nützlich sein können – vor der Antragstellung, während der Förderung oder ganz allgemein in der Entwicklung von Freier und Open-Source-Software!

1. Wie sieht eine Welt aus, in der mein Projekt existiert?

Wenn wir Teams nach ihrer Vision für ihr Projekt fragen, beschreiben die meisten Entwickler*innen, welches Produkt sie bauen. „Ich baue ein Werkzeug, das XYZ macht“, ist die Standardantwort. Das ist zwar eine absolut berechtigte Aussage, aber wir versuchen immer, unsere geförderten Projekte bei der Definition ihrer Vision etwas weiter voranzutreiben. Hier solltet ihr euch das Gesamtbild vorstellen: Wie sieht eine Welt aus, in der euer Projekt existiert und genutzt wird?

Es geht hier darum, nicht nur das Wie, sondern auch das Warum in Worte zu fassen. Wer eine klare Vorstellung des Ziels hat, kann klarer über das Projekt kommunizieren und läuft nicht Gefahr, sich in zusätzlichen Features und anderen Sackgassen der Softwareentwicklung zu verlieren.

2. Brauchst du dieses Feature wirklich?

Die meisten Förderungen sind mit einer Frist verbunden – beim Prototype Fund haben Projekte 6 Monate Zeit, an ihren Prototypen zu arbeiten. Ein halbes Jahr hört sich zwar viel an, aber wenn ihr versucht, etwas ganz Neues zu bauen, kann die Zeit schneller vergehen als erwartet. Es ist hilfreich, sich alle paar Wochen Zeit zum Nachdenken zu nehmen: Wie viele Meilensteine habe ich erreicht? Werde ich in der Lage sein, alle geplanten Features bis zum Ende meiner Förderzeit umzusetzen?

Wenn die Antwort darauf “nein” lautet, dann solltet ihr euch überlegen, ob ihr nicht die Extras aufgeben solltet, von denen ihr geträumt habt, und euren Plan auf das Wesentliche reduzieren wollt. Ein einfaches Werkzeug, das gut funktioniert, bringt Menschen viel weiter als ein Multifunktionswerkzeug, das kaum funktioniert.

3. Ohne Dokumentation ist alles nichts

Wir können es nicht oft genug wiederholen: Stellt sicher, dass ihr ausreichend Zeit für die Dokumentation habt! Ja, Dokumentation ist zeitaufwendig, dennoch gibt es keinen Weg daran vorbei: Wer sein Projekt erklärt oder gut beschreibt, wie sein Code funktioniert, macht es somit anderen Personen zugänglich, die es benutzen oder dazu beitragen können.

Dokumentation kann viele Formen annehmen, je nachdem, an welcher Art von Projekt ihr arbeitet: Ihr könnt euren Code selbst dokumentieren, damit andere Entwickler*innen ihn verstehen, verwenden und dazu beitragen können. Ihr könnt Blogposts veröffentlichen, die erklären, wie das Projekt funktioniert. Ihr könnt auch Admin-Dokumente für Menschen schreiben, die eine Instanz des Tools einrichten wollen. Oder ihr erstellt Tutorials, die Endbenutzer*innen helfen.

4. Code ist nicht alles

Das Tolle an Open Source ist, dass man nie wirklich allein ist. Open-Source-Software zu entwickeln bedeutet, dass man Teil einer größeren Community ist, in der viele Menschen potenziell bereit sind, zu helfen. Förderer versuchen in der Regel, Projekte mit nützlichen Informationen und zusätzlichen Ressourcen zu unterstützen. Zum Beispiel bieten wir beim Prototype Fund Coachings, Informationen zur Anschlussfinanzierung, Veranstaltungshinweise und andere nützliche Tipps an und versuchen, den Teams interessante Kontakte zu vermitteln.

Obwohl es verlockend sein kann, sich ausschließlich auf den Code zu konzentrieren, solltet ihr nicht vergessen, die zusätzlichen Ressourcen zu nutzen, zu denen ihr Zugang habt. Einige Stunden in einem Design-Coaching zu verbringen, kann euch dabei helfen, größere Mängel zu identifizieren, die ihr ohne externe Hilfe nicht sehen könntet; ein Projekt auf einer Veranstaltung zu präsentieren, auch wenn es noch nicht fertiggestellt ist, kann sehr nützliches Feedback liefern; sich Zeit zu nehmen, um eine schöne Website einzurichten, kann neue Benutzer*innen oder Beiträge einbringen. Code ist nicht alles.

5. Das richtige Team finden

Im Team zu arbeiten ist ein guter Weg, zusätzliche Fähigkeiten in ein Projekt einzubringen. Beim Prototype Fund könnt ihr nach Beginn der Förderzeit das Team nicht mehr wechseln, aber fehlende Fähigkeiten im Team können ein Projekt ernsthaft verzögern – daher ist es besonders wichtig, von Anfang an das richtige Team zusammenzustellen. Bei der Bewerbung solltet ihr die folgenden Fragen im Hinterkopf haben:

Welche Art von Menschen brauche ich, um ein starkes Team aufzubauen?
Verfüge ich alleine über alle notwendigen Fähigkeiten?
Brauche ich jemanden, der sich mit Design oder Sicherheit auskennt oder andere besondere Fähigkeiten in meinem Team mitbringt?

Wer früh Zeit und Energie in die Suche nach den richtigen Teammitgliedern investiert, hat später mehr davon.

6. Vielfalt ist Stärke

Beim Aufbau eines Teams geht es nicht nur um Fachkenntnisse sondern auch um Menschen, ihre Erfahrungen und die Art und Weise, wie sie an ein Projekt herangehen. Wer ein Team zusammenstellt, sollte deswegen immer möglichst große Vielfalt anstreben. Menschen mit unterschiedlichen Hintergründen werden dasselbe Projekt mit einem anderen Blick betrachten – und ein vielfältiges Team wird die Bedürfnisse einer großen, vielfältigen Benutzer*innengruppe besser verstehen.

Um das Beste aus einem vielfältigen Team zu machen, ist es wichtig, eine gesunde Kommunikationskultur zu etablieren und sicherzustellen, dass alle unterschiedlichen Ansätze und Meinungen gehört werden können. So wird ein Projekt nur noch stärker!

7. Nutzer*innen gehen vor

Wenn ihr als Entwickler*innen ein Projekt beginnt, glaubt ihr natürlich, dass am Ende ein gutes Ergebnis dabei herauskommt. Ihr müsst aber eure potenziellen Nutzer*innen einbeziehen um herauszufinden, ob euer Produkt wirklichen einen Nutzen für sie hat. Wir können gar nicht genug betonen, wie hilfreich es sein kann, vor dem Start Nutzer*innenforschung zu betreiben und Nutzer*innentests durchzuführen, sobald eine Version vorliegt, die getestet werden kann (das kann auch nur ein Prototyp auf Papier sein). Dabei solltet ihr auch daran denken, Zeit einzuplanen, um auf der Grundlage des Feedbacks Änderungen vorzunehmen!

8. Communities aufbauen (oder beitreten)

Open Source basiert auf Communities. Ob ihr einen Beitrag zu einem bestehenden Ökosystem leistet (wie z. B. zu einem existierenden Betriebssystem) oder etwas neues aufbaut – wenn ihr Teil einer Community seid, ist das der beste Weg zum Aufbau eines nachhaltigen Netzwerks von Beitragenden. Es hilft, sich selbst und die eigene Idee so früh wie möglich in Communities vorzustellen, die dem Projekt nahe stehen, und von deren Erfahrung zu profitieren. Setzt euch mit Menschen in Verbindung, die möglicherweise an ähnlicher Software arbeiten und sucht Personen, die die Kompetenzen eures Teams ergänzen.

9. Partner*innen finden

Wie bei den Communities kann es auch sehr hilfreich sein, potenzielle Partner*innen früh genug anzusprechen. Zum Beispiel: Bei der Arbeit an einer Software für den Gesundheitsbereich könnt ihr euch an Krankenhäuser wenden, um gemeinsame Tests zu planen und Feedback von Gesundheitsexpert*innen zu erhalten. Bei der Arbeit an Software im Bildungsbereich, könnt ihr Lehrer*innen nach ihren Bedürfnissen fragen und somit sicherstellen, dass die Software tatsächlich nützlich für die Zielgruppe ist. Auch Universitäten, NGOs und Museen haben sich für einige unserer Projekte in verschiedenen Bereichen als sehr nützlich erwiesen.

10. Nicht das Rad neu erfinden – aber mal den Reifendruck prüfen

Open-Source-Ökosysteme sind eine Welt aus Einzelteilen, die recycelt und angepasst werden können, z. B. in Form von Packages und Libraries. Warum Zeit mit dem Versuch verlieren, etwas neu zu bauen, das bereits gut funktioniert? Verschafft euch am besten bereits während der Bewerbungsphase – spätestens aber bevor ihr mit dem Coden loslegt – eine genaue Orientierung über die Dependencies eures Codes (das geht z. B. super mit libraries.io). So könnt ihr effizienter arbeiten und verschwendet keine Energie an etwas, das es schon längst gibt.

Stattdessen könnt ihr etwas Neues entwickeln, bestehende Codebausteine erweitern und überarbeiten, besondere Features implementieren, Nutzer*innentests durchführen oder Vorträge vorbereiten. Nutzt eure Zeit lieber dafür!

Vergesst dabei nicht, dass Recycling auch Zeit kostet: Schnittstellen funktionieren nicht immer wie vorgesehen, neue Implementierungen können nötig sein und einzelne Funktionalitäten sind nicht immer kompatibel. Es ist im Sinne des Open-Source-Gedankens, Upstream zurückzugeben und diese Probleme zu beheben. Verliert dabei aber nicht aus dem Blick, dass auch diese Wartungsarbeiten in eure Meilensteinplanung passen müssen.

11. Die Zukunft wartet nicht

Eine sechsmonatige Förderung ist toll. Aber was kommt danach? Während einige Projekte von ehrenamtlichen Communities gepflegt werden können, brauchen andere finanzielle Mittel, um zu überleben. Egal, ob das Projekt weiter von Fördergeldern finanziert oder ob ein Geschäftsmodell entwickelt werden soll: Wartet nicht ab, bis das Geld ausgeht, bevor ihr euch nach dem nächsten Einkommen umseht.

Bevor die Förderzeit vorbei ist, solltet ihr euch überlegen, welche Zukunft ihr euch für euch, das Team und das Projekt wünscht, und versuchen, ein nachhaltiges Modell aufzubauen. Fragt euch: Wie soll es weitergehen?

12. Pausen machen!

Bei der Arbeit an einem Projekt gibt viel zu viel zu tun und viel zu wenig Zeit! Wenn ihr anfangt, der, der Zeit hinterherzulaufen, vergesst ihr oft auch, auf euch zu hören. Deswegen nehmt euch diesen Ratschlag besonders zu Herzen: Pausen gehören dazu! Nehmt euch frei, wenn ihr es braucht. Wenn Körper und Geist erholt sind, geht auch die Arbeit am Projekt wieder besser voran.