staging.inyokaproject.org

Aktueller Entwicklungsstand von GIMP 2.8

gnome-gimp.png

Mittlerweile ist es schon fast zwei Jahre her, seitdem GIMP 2.6 - die aktuelle Version - erschienen ist. Seitdem wird mit Spannung erwartet, wie die neue Version 2.8 aussehen wird. Leider verzögert sich der Releasetermin immer wieder, weswegen auch bis heute die finale Version des freien Bildbearbeitungsprogrammes noch nicht fertiggestellt wurde.

GIMP 2.8 wird von vielen Benutzern sehnsüchtig erwartet, da es viele große und kleine Neuerungen gegenüber der aktuellen Version geben wird. Zwischenzeitlich konnte man den aktuellen Entwicklungsstand im Zuge der „Zwischenversion“ 2.7 betrachten und ausprobieren. Allerdings sind Versionen mit ungerader Endung nicht als vollwertige Entwicklungen anzusehen. Doch wie sieht es mit dem momentanen Fortschritt aus? Vor etwas mehr als einem Jahr, im Januar 2010, kündigten die Entwickler von GIMP an, 2.8 im Dezember 2010 fertigzustellen. Leider mussten sie im Laufe des Jahres dieses Datum mehrfach korrigieren, so dass es momentan so aussieht, als würde das Programm erst im zweiten Quartal 2011 erscheinen. Einer der Entwickler, Martin Nordholts, hat sich in seinem Blog dazu geäußert, warum es so lange dauert, bis v2.8 endlich erscheint. In seinem Artikel führt er drei Hauptgründe auf, warum es länger dauert, die neue Programmversion zu veröffentlichen:

  • Das Projekt wird ausschließlich von Freiwilligen entwickelt. Bei diesen Freiwilligen handelt es sich um ganz normale Menschen, die Höhen und Tiefen in ihrem Privatleben durchleben. Deswegen können sie sich manchmal mehr, manchmal weniger um das Projekt kümmern. Dieses Auf und Ab verzögert die Entwicklung.

  • Neue Funktionen des Programms werden gleich im Hauptableger entwickelt. Dadurch dass viele Entwickler nur zeitweise für GIMP arbeiten, kommt es immer wieder vor, dass irgendeine Funktion im Hauptableger nicht fertig ist und diese deswegen nicht fertiggestellt werden kann. Das macht GIMP für Programmierer gleichzeitig auch unattraktiv, da es sprichwörtliche Jahre dauert, bis ihre fertigen Features an die breite Masse kommen und somit Feedback von den Benutzern kommt.

  • Der letzte Grund, den Martin in seinem Artikel anspricht, ist ein weiterer menschlicher Aspekt: Die Programmierer bevorzugen die leichte, spannende Arbeit beim Programmieren. Sobald es bei manchen Funktionen ans Eingemachte geht, wo es kompliziert und langweilig wird, starten sie lieber etwas neues. Darum gibt es in GIMP jede Menge angefangene Funktionen, leider nicht alle beendet.

Um aus diesem Teufelskreis zu entkommen, gibt Martin einen Vorschlag ab, wie man fast alle Probleme lösen könnte: statt alles im Hauptprogramm zu entwickeln, sollte man die einzelnen Teile separat zu Ende führen und erst wenn sie fertig sind, sollen sie ins Hauptprogramm aufgenommen werden.

Veröffentlicht von Nooster | 23. Februar 2011 12:00 | Kategorie: Linux und Open Source | # Fehler im Artikel melden

burli

Avatar von burli
1 23. Februar 2011 12:54

Ich denke, die Änderung ist sinnvoll. Und ich denke, es wäre auch sinnvoll, wie Chrome oder demnächst Firefox lieber in kürzeren Abständen kleinere Änderungen zu bringen als einmal in einer Dekade ein komplett neues Programm. Gerade bei den genannten Schwierigkeiten könnten viele kleine Schritte besser funktionieren als zu versuchen, mit aller Gewalt einen großen zu machen.

So können auch Fehler schneller ausgebessert werden und müssen nicht 2 Jahre mitgeschleppt werden.

Yanneck

Avatar von Yanneck
2 23. Februar 2011 12:58

Das hört sich doch sehr sympathisch an: Komme ich heute nicht, komme ich morgen. Vielleicht. Ich finde, die sollten einfach so weitermachen. 😀

Rockiger

Avatar von Rockiger
3 23. Februar 2011 13:05

Wie könnte man dem Gimp-Team ermöglichen vollzeit an Gimp zu arbeiten?

Ich glaube hier ließe sich viel gewinnen. Gute Software zu schreiben ist viel und harte Arbeit, das immer nur in der Freizeit zu machen ist, aus meiner Sicht, suboptimal.

burli

Avatar von burli
4 23. Februar 2011 13:07

@3: Spenden Spenden Spenden.

Oder Canonical stellt neben dem Compiz Entwickler, dem Docky Entwickler und dem OOo Entwickler noch einen Gimp Entwickler ein 😉

burli

Avatar von burli
5 23. Februar 2011 13:13

@2: Das wäre schlecht. So wie ich das verstehe ist die derzeitige Struktur bei der Entwicklung so ziemlich die schlechteste Option. Weil alles im Hauptzweig läuft behindern sich alle Entwickler gegenseitig. Jeder Entwickler bräuchte schonmal einen eigenen Branch, in dem er werkeln kann, ohne die anderen zu stören. Da ist es dann egal, wie lange der einzelne braucht, um eine Funktion fertig zu stellen. Man kann ein neues Release eben mit dem rausbringen, was fertig ist.

Rockiger

Avatar von Rockiger
6 23. Februar 2011 14:57

@4: Ja, soll jeder aktive Anwender mal den Betrag spenden, den er für kommerzielle Bildbearbeitungs-Software ausgeben müsste. Leider machen die Leite das nicht.

axt

7 23. Februar 2011 15:04

@4:

noch einen Gimp Entwickler ein 😉

Ausgerechnet Canonical, die Gimp aus den Ubuntu-Images verbannt haben.

devvv

8 23. Februar 2011 15:07

Ich denke viele Entwickler werden von GIMP abgeschreckt weil die ganzen Informationen zur Entwicklung, zum Einstieg, an vielen Orten verteilt sind. Zum einen soll man direkt Kontakt aufnehmen im IRC (wobei man als Neuer nicht weiß wer denn überhaupt Entwickler sind), zum anderen sind Informationen zur Entwicklung auf gimp.org, git.gnome.org, dem gnome-bugtracker verteilt... Dann gibt es noch ein gimp wiki das ab und zu down ist, eine roadmap, eine timeline und verschiedene andere orte mit Informationen. Was GIMP braucht ist neben den Dingen die Martin Nordholts angeführt hat ein Bounty-System für kleinere Bugs (Geld ist ja genug da) (s. http://www.gimpusers.com/mailmsg.php?1295300803.15278.11.camel@bender) und eben ein Zentrum wo neue Entwickler gleich einen Gesamtüberblick für GIMP bekommen.

Nebenbei: Wir hatten auf gimpusers.de eine sehr umfangreiche Vorschau mit allen Details zu GIMP 2.8: http://www.gimpusers.de/tutorials/gimp-28-feature-preview-april-2010 😉

burli

Avatar von burli
9 23. Februar 2011 15:16

@7: Ich glaube, so ganz freiwillig war das nicht. Canonical hält an der 700MB Größe fest. Und da der Rest immer größer wird muss halt das "unwichtigste" weichen. Und für die meisten dürfte Gimp relativ unwichtig sein.

DeKiesel

10 23. Februar 2011 16:45

ich halte das festhalten an der 700mb grösse auch für wichtiger. gimp installiere ich zwar immer direkt nach, aber lieber so als einen dvd statt cd-rohling zu brauchen.

burli

Avatar von burli
11 23. Februar 2011 16:52

@10: Genau. Für uns in Europa oder so ist es ja kein Problem. Ich installiere seit Jahren nur noch per USB Stick. Aber Ubuntu will ja auch in Ländern nutzbar sein, bei denen solch moderne Technologien noch nicht angekommen sind.

Ximion

Avatar von Ximion
12 23. Februar 2011 18:30

@5: Wie sind die überhaupt auf diese Idee gekommen? Der Zweck einer Versionsverwaltung ist ja gerade, nicht im Hauptzweig zu Entwickeln, sondern Features in eigenen Zweigen fertig zu stellen und dann in den master-Zweig einzupflegen.

burli

Avatar von burli
13 23. Februar 2011 18:41

@12: Gute Fragen nächste Frage

snafu1

Avatar von snafu1
14 23. Februar 2011 23:00

@4: Wie stellst du dir das vor? Sollen die Leute dann 3 Wochen von ihrem Job fernbleiben, weil der Lohn für die Zeit ja gespendet wurde? Ich glaube, die meisten Chefs fänden das nicht so toll.

bernd1

Avatar von bernd1
15 24. Februar 2011 08:01

@8: Super Auflistung bei gimpusers.de. Die Liste zeigt, wieviel Arbeit sich die Entwickler mit der neuen Version machen. Danke für den Link!

blu35cr3w

16 24. Februar 2011 12:37

In meiner Firma sind wir mit einem ähnlich gelagerten Problem geschlagen. Das kann man nur umgehen in dem man, wie vorher schon erwähnt, funktionsbezogen entwickelt. Und nicht wie jetzt aktuell bei mir eine alte Arbeitsweise auf Git heruntergebrochen wird.

Gimp 2.8 soll sich die Zeit nehmen, die es benötigt!

mpathy

Avatar von mpathy
17 26. Februar 2011 09:15

Naja etwas wird dabei verschwiegen: Das Core-Team von GIMP bzw. die die immer die gleichen geblieben sind dort, haben ihre ganz genauen Vorstellungen was sie in GIMP haben wollen und was nicht. Dies gehen teilweise krass gegensätzlich zu dem was die breite Masse an Usern will. Man braucht da nur an die Diskussion GIMP & CMYK-Unterstützung denken - das ist für viele das allerwichtigste seit Jahren, das in die Software muss, es melden sich auch ab und zu Leute die das Umsetzen wollen, aber nein.. Erinnert einen ein wenig an andere Projekte - wenn ich mich recht entsinne ist auch Ubuntu teils aus der Unflexibiltät einer auf der gleichen Basis stehenden Distribution entstanden ☺ Naja ich persönlich muss so wie die Dinge laufen für Bildbearbeitung weiter auf Photoshop setzen während ich in anderen Bereichen bereits auf Open Source umgestellt habe (Scribus, Inkscape, Xara etc.) ich schaue ehrlich gesagt auch stärke auf neue Versionen von Krita - http://krita.org/ + kann natürlich auch Bilder für den Druck (CMYK) bearbeiten! - als von GIMP bei denen sich von den Leuten so schnell nichts ändern wird.

Lambrusco

18 28. Februar 2011 18:53

Natürlich lese ich gerne, dass evtll. 2011 noch GIMP 2.8 erscheinen soll! Wobei ich gestehen muss, dass ich GIMP 2.6 auch noch nicht voll beherrsche und bei manchen Arbeiten immer noch nach Hilfe googeln muss. Der größte Fortschritt für mich wäre, wenn GIMP 2.8 endlich auch voll mit Mehrkern CPU s zurecht kommen würde, was ja bei 2.6 noch nicht der Fall ist.

gscholl

19 9. Juli 2011 22:48

Dass die GIMP-Entwicklung nur einen Hauptzweig hat, hört sich für mich eher gruselig an – und noch dazu unprofessionell. Das kann man sich leisten, wenn man gaaanz alleine im stillen Kämmerlein vor-sich-hin- bastelt(selbst da macht man schon Back-ups, oder?)- nicht als großes OpenSource-Projekt. Viele Leute machen ja wohl die ersten Erfahrungen mit OpenSource über solche Programme wie GIMP. Und wenn sie nicht sehen, dass es dabei weitergeht, wird eben weiter gephotoshopt; das kann nicht in unserem Sinn liegen, dass wir als Community dadurch "Werbung" verlieren.

Liebe GIMP-Entwickler, macht bitte, dass ihr Land gewinnt!