Ich verstehe nicht was du meinst? Freetz ist ein Projekt, dass wir alle in der Freizeit machen. Wie würdest du die Roadmap denn festlegen? Ich denke nicht, dass es sinnvoll ist feste Termine anzugeben.
wenn ich "roadmap" wortwörtlich übersetze und mir einen strassenatlas anschaue, kann ich dort keine zeiten finden. hier sind wege verzeichnet, wie ich von einem zwischenziel zum anderen zwischenziel komme bis ich letztendlich mein ziel erreicht habe. hier kann ich bei bedarf auch alternativrouten nehmen, wenn es die situation verlangt...
das grundlegende dabei ist die reihenfolge: ich muss zuerst die strasse A befahren, um zur strasse B zu kommen um dann mein zwischenziel C zu erreichen. andersrum geht es einfach nicht...
und bei einer roadmap für ein projekt werden erst im 2. schritt zeiten festgelegt. projektmanagmentsyteme erlauben mittlerweile sogar nicht mal mehr feste termine für meilensteine, sondern gehen davon aus, das es sich hier um eine zeitspanne handelt (was auch meist der realität entspricht). im fall von Freetz machen feste termine für meilensteine aus genanntem grund auch keinen sinn, darum geht es mir auch nicht.
man kann heutige softwareprojekte nicht mehr mit projekten von vor 20 jahren vergleichen. die ansprüche der anweder sind ganz anders und die komplexität auch. es ist nicht mehr damit getan, die software zu erstellen. sie lebt weiter und muss gepflegt werden. mittlerweile beanspruchen pflege und wartung weit über 50% der gesamten entwicklungszeit.
kontraproduktiv ist dann in einigen fällen auch noch die einstellung der entwickler. vorallem bei jüngeren leuten herrscht oftmals die einstellung: "wichtig ist doch erstmal das es funktioniert. schick mach ich das dann später..."
in einem business-projekt hat man oftmals nicht die zeit, das dann zu realisieren. in einem opensource-projekt haben die leute dann oftmals keinen bock mehr, das zu realisieren und befassen sich dann lieber wieder mit neuen sachen.
weiterhin erschwerend kommt hinzu, das anwender bzw. aussenstehende ein neues release nur anhand der neuen features messen. dies ist eine geisel der zeit. immer kürzere release-zyklen mit immer mehr unsinnigen features nur um den vergleich zur kokurrenz standhalten zu können. robustheit und stabilität ist heute kein verkaufsargument mehr...
um jetzt den bogen wieder zu Freetz zu bekommen: gerade hier halte ich stabilität, robustheit und eine solide basis für weitaus wichtiger als tausende von paketen. in der roadmap vermisse ich den roten faden und vorallem feature freezes. es wäre wirklich schade, wenn man sich hier dem zeitgeist hingeben würde und sich auch nur noch an features orientiert. hier sollte man sich auch nicht dem druck der user im forum hingeben sondern ruhig und gewissenhaft die basis pflegen und wenn dann noch zeit ist, neue sachen zu integrieren...
genau diesen weg haben wir seit einigen jahren eingeschlagen und laufen damit recht gut. da kommt bei einigen entwicklern nicht immer freude auf, wenn man neue ideen einfach mal so abschmettert. es landet damit auch nicht jeder mist sofort im CVS, erst wird ausgiebig getestet, dann eingecheckt. gerade bei verteilter entwicklung ist das gold wert. es muss sich nicht jeder mit den kinderkrankheiten rumschlagen. der trunk bekommt eine ganz andere qualität und entspricht zu über 90% bereits dem nächsten stable release.
und wenn ich jetzt mal so die letzten 10 jahre zurückblicke konnte der zeitaufwand für pflege und wartung bei projekten und frameworkmodulen auf unter 5% gedrückt werden.
und diese philosophie lebe ich seit über 20 jahren in der softwareentwicklung (davon 16 jahre im industriellen umfeld). ich würde mir wünschen, wenn sich davon was in der Freetz roadmap widerspiegeln würde, deshalb der kleine anreiz mit den 50eur.
meine meinung muss hier keiner teilen, ich hoffe, sie ist jetzt ein wenig besser rübergekommen als nur der eine satz im ausgangsposting
Ich überleg mir ja nicht, wenn ich aus dem Fenster schaue: "Oh heute sieht das Wetter nach Branch ziehen aus...".
hmm, ich zitier hier jetzt mal nicht das posting zum 1.2er branch
