Ich habe im Laufe der Zeit viele Projekte betreut, und vor allem häufig parallel betreut - es macht mir sogar Spaß, immer zwischen den Projekten hin- und herzuspringen, wie es die Anforderungen gerade gebietet. Dabei ist es natürlich nützlich, wenn man immer ein paar Werkzeuge zur Hand hat, die übergreifend einsetzbar sind. Und auch wenn normale Programmierplattformen (Perl, Java, etc) für vieles hinreichende Bordmittel bereitstellen, so braucht es doch oft mehr.

Ein Projekt, dass mittlerweile schon recht lange läuft, ist das Autoconf Macro Archive. Es basiert auf der Tatsache, dass ich die Build-Struktur vieler Unix-orientierter Software mit Hilfe der GNU Autotools erstellt habe - Autconf, Libtool, Automake. Alle Erweiterung hatte ich mir zunächst in einem privaten Archiv zusammengefasst, als jedoch die Idee zu einem Community Projekt im Netz kam, habe ich mich dessen angenommen. Dort (auf Sourceforge) gibt es mittlerweile viele hundert Makros.

Eine andere Variante war die Zusammenfassung von Schnippseln, die im Build-Prozess eingesetzt werden - zum einen ist da das mksite.sh Tool, ein Unixshell-Skript mit der auch die vorliegenden Seiten erstellt sind, und so ziemlich Alles enthält, was sonst als kurze Zeilen zur Html-Synthese in Makefiles stand. Aber auch das XM-Tool sollte man hier erwähnen, das ähnliches auf der Basis von Perl verfolgte.

Mit steigender Erfahrung habe ich viele private Werkzeuge und Erweiterungen in Form von Miniprojekten aufbereitet, und als Opensource zur Verfügung gestellt. Da ist etwa das MPEGsplit Projekt, das RunSO (statt RunDLL), das SDLstretch, und vieles andere (meist bei Sourceforge zu finden).

Leider sind diese Projekte immer etwas Platform-gebunden. Erst seit kurzem mit steigender Verbreitung von .NET und dessen multiplen Frontends gibt es neue Hoffnungen - denn man ist nun nicht mehr nur an Java/C++ ähnliches C# gebunden, man kann auch Skriptsprachen wie Python in ein wiederverwendbares Modul kompilieren, und eine objekt-orientierte Shell einsetzen. Ich hoffe da persönlich sehr, dass dieses aufgegriffen wird, und man davon abkommt, alles in Java-Code umzuschreiben, denn diese ist nicht für alle Problemstellungen gut geeignet. (Sprichwort: Wer nur einen Hammer hat, der betrachtet jedes Problem als einen Nagel).

Es sei hier noch dazugesagt, dass es immer sinnvoll ist, ein Archiv nicht nur anzulegen, sondern auch ordentlich aufzubereiten und zu präsentieren, damit die Anteile auch von dritter Seite wiederverwendet werden können - die einem dann auch nur allzuoft sehr nützliches Feedback geben, seien es Erweiterungen oder nur Bugfixes. Es steht in der Natur der Sache, dass diese Archive sehr speziell sind, und teils verschiedenstartige Quellen präsentieren, aber es steht hier auch meine Erfahrung in den Doku Compilern zur Hilfe.