Wie von mquadrat bereits angedeutet kann man es über Manifest-Dateien sicherstellen, dass nur die Komponenten angeboten werden, die mit der eingesetzten Delphi-Version funktionieren. Ebenso lässt sich über einen Download-Zähler und ein Bewertungssystem einiges an Frust ersparen, wenn man schon vor dem Download sieht, dass eine Komponente in zwei Jahren nur zehn mal heruntergeladen wurde.

Für den NuGet-Manager kann jeder Pakete hinzufügen und es funktioniert hervorragend. Ein Github-Repository kann automatisch mit NuGet synchronisiert werden und bleibt so stets aktuell. Als NuGet-User kann ich in meinem Projekt nach Updates suchen und erhalte Informationen zu allen eingesetzten Fremdbibliotheken. Der Wartungsaufwand ist gering. Wenn ein Paket nicht mehr passt oder fehlerhaft ist, finde ich für viele Aufgaben schnell eine passende Alternative.
In meinen C#-Projekten setze ich daher viel mehr fremden Code ein als in Delphi. Cryptographie, JSON-Serialisierung, Anbindung an diverse REST-Services, GUI-Komponenten etc. erhalte ich per Knopfdruck genauso wie die dazugehörigen Aktualisierungen.
Bei Delphi muss ich wie in den neunziger Jahren und den frühen zweitausendern auch weiterhin regelmäßig die Projektseiten der eingesetzten Fremdkomponenten abklappern. Wenn eine Bibliothek nicht mehr weiterentwickelt wird, beginnt die große Suche nach Alternativen in diversen Delphi-Foren und auf Stackoverflow. Das ist mühselig und führt häufig genug dazu, dass in Delphi-Projekten möglichst wenig Fremdsource eingesetzt wird und das Entwicklerteam folglich Dinge implementieren muss, die tausende andere Entwickler bereits vor Jahren geschrieben haben. Ja, es hat auch Vorteile wenn ein Team allen genutzen Source selbst geschrieben hat. Aber mit "Rapid Application Development" hat das nichts zu tun. RAD war die große Stärke von Delphi in seiner Hochzeit. Damals benötigte man für RAD nur einen UI-Designer in der IDE. Heute ist ein UI-Designer vernachlässigbar geworden. Durch automatisches Layouting lassen sich schöne GUIs auch schnell im Code schreiben.

Heute geht es bei RAD eher darum
- bestehende ausgereifte Komponenten schnell und zuverlässig einsetzen zu können
- Code vernünfitg refactoren zu können
- Schnell durch große Projekte zu navigieren (Wo wird Klasse XY verwendet? Wer ruft Funktion x() auf? Wer implementiert Interface I? etc.)
- Schnell sehen können, ob und wo ein Unit-Test fehlschlägt und welche Codezeilen gar nicht getestet werden

In all diesen Disziplinen hinkt auch Delphi XE8 der Konkurrenz weit hinterher. Mit RAD hat das nichts mehr zu tun. Für eine marktreife Applikation (beginnend auf der grünen Wiese) brauche ich mit Delphi aufgrund der oben genannten Punkte heute erheblich länger als mit C# oder Java. Wo ist eigentlich das Alleinstellungsmerkmal von Delphi geblieben? Was ist das große Argument gegenüber C++, C# oder Java? RAD ist es seit einigen Jahren nicht mehr.

Mit GetIt könnten sie zumindest ein bisschen in Richtung RAD rudern aber daran haben sie offenbar kein Interesse.

Danke für den Link. TestInsight habe ich kurz mit XE6 angetestet als ich auf DelphiFeeds davon erfahren habe. Innerhalb von zwanzig Minuten habe ich es nicht ans Laufen gebracht und wieder entfernt. Vielleicht gebe ich dem Projekt in Zukunft noch mal eine Chance. Die Idee hinter dem Projekt halte ich jedenfalls für richtig.