代码交完不等于差事交完🔥😵 Viele feiern schon, wenn das Repository des Grant-Projekts online geht, und denken: „Geschafft.“
Aber als ich die Anforderungen des @Dusk Grants Program gelesen habe, hat sich mein Blick am letzten Milestone festgebissen: Bewerber müssen einen Wartungsplan für ein Jahr einreichen.
Ein Jahr. Nicht „wenn es ein Problem gibt, einfach ein Issue melden“, sondern eine harte Pflicht – schwarz auf weiß in der Lieferliste.
Dusk verlangt außerdem passende Dokumentation, Tests und nachstellbare Installations- und Ausführungsschritte. In normaler Sprache heißt das: Du bekommst ein unterstützendes Team – aber du kannst die Funktionen nicht nur am Demo-Tag anknipsen. Du musst dafür sorgen, dass die späteren Leute sie übernehmen und weiter reparieren können.
Demo ist leicht, Wartung kostet
Für die Antragsteller ist es kurzfristig gar nicht so schwer, ein Demo zu bauen, das läuft. Code schreiben, der funktioniert, Demo-Tag überstehen.
Wirklich teuer wird es erst nach einem Jahr: Abhängigkeiten sind geupdatet, jemand meldet ein Issue, und die Befehle in der Dokumentation laufen nicht mehr.
Dann stellt sich die Frage: Ist das Team in dem Moment noch bereit, zurückzukehren und es zu fixen? Wenn ja – wer macht das? Und gibt es in eurem Budget dafür Arbeitsstunden?
Viele Projekte liefern ihre erste Version aus, und die Kernmitglieder sind dann weg, um sich anderen Dingen zu widmen. Das Repository ist noch da, aber die Nutzer kommen, können nicht installieren, und niemand antwortet. Die Kosten verschwinden nicht – sie verlagern sich nur zum nächsten Entwickler im Ökosystem. Das kann dann wieder du sein oder ich.
Diese Anforderung ist ein Filter
Ich glaube nicht, dass Dusk mit dieser Anforderung sicherstellen kann, dass jedes Projekt langfristig aktiv bleibt. Ganz ehrlich: Eine Bewerbung allein garantiert nichts.
Aber sie macht zumindest eine Sache richtig: Sie stellt die Kosten für „Wartung“ schon im Voraus in den Antrag.
Teams, die bereit sind, ein Jahr Wartung ins Budget zu schreiben, wollen eher eine Infrastruktur liefern als nur eine einmalige Aufgabe abgeben. Den Unterschied kann man in der Antragsphase nicht sehen – aber nach einem Jahr, wenn man den Stand des Repositories überprüft, ist es auf einen Blick klar.
$DUSK – Was danach wirklich zählt, ist, ob @Dusk diese Wartungsfortschritte und den Status der Repositories öffentlich macht. Sichtbare Daten sind ehrlicher als jedes Versprechen. Damit das Ökosystem von #dusk wachsen kann – nicht nur eine Menge Repos, die kurz online gehen und dann verstummen😖.
Aber als ich die Anforderungen des @Dusk Grants Program gelesen habe, hat sich mein Blick am letzten Milestone festgebissen: Bewerber müssen einen Wartungsplan für ein Jahr einreichen.
Ein Jahr. Nicht „wenn es ein Problem gibt, einfach ein Issue melden“, sondern eine harte Pflicht – schwarz auf weiß in der Lieferliste.
Dusk verlangt außerdem passende Dokumentation, Tests und nachstellbare Installations- und Ausführungsschritte. In normaler Sprache heißt das: Du bekommst ein unterstützendes Team – aber du kannst die Funktionen nicht nur am Demo-Tag anknipsen. Du musst dafür sorgen, dass die späteren Leute sie übernehmen und weiter reparieren können.
Demo ist leicht, Wartung kostet
Für die Antragsteller ist es kurzfristig gar nicht so schwer, ein Demo zu bauen, das läuft. Code schreiben, der funktioniert, Demo-Tag überstehen.
Wirklich teuer wird es erst nach einem Jahr: Abhängigkeiten sind geupdatet, jemand meldet ein Issue, und die Befehle in der Dokumentation laufen nicht mehr.
Dann stellt sich die Frage: Ist das Team in dem Moment noch bereit, zurückzukehren und es zu fixen? Wenn ja – wer macht das? Und gibt es in eurem Budget dafür Arbeitsstunden?
Viele Projekte liefern ihre erste Version aus, und die Kernmitglieder sind dann weg, um sich anderen Dingen zu widmen. Das Repository ist noch da, aber die Nutzer kommen, können nicht installieren, und niemand antwortet. Die Kosten verschwinden nicht – sie verlagern sich nur zum nächsten Entwickler im Ökosystem. Das kann dann wieder du sein oder ich.
Diese Anforderung ist ein Filter
Ich glaube nicht, dass Dusk mit dieser Anforderung sicherstellen kann, dass jedes Projekt langfristig aktiv bleibt. Ganz ehrlich: Eine Bewerbung allein garantiert nichts.
Aber sie macht zumindest eine Sache richtig: Sie stellt die Kosten für „Wartung“ schon im Voraus in den Antrag.
Teams, die bereit sind, ein Jahr Wartung ins Budget zu schreiben, wollen eher eine Infrastruktur liefern als nur eine einmalige Aufgabe abgeben. Den Unterschied kann man in der Antragsphase nicht sehen – aber nach einem Jahr, wenn man den Stand des Repositories überprüft, ist es auf einen Blick klar.
$DUSK – Was danach wirklich zählt, ist, ob @Dusk diese Wartungsfortschritte und den Status der Repositories öffentlich macht. Sichtbare Daten sind ehrlicher als jedes Versprechen. Damit das Ökosystem von #dusk wachsen kann – nicht nur eine Menge Repos, die kurz online gehen und dann verstummen😖.