[gnucash-de] Re: Kontenplaene, zum zweiten

[Christian Stimming]

Hallo Andreas,

Andreas Schenk schrieb:
> Sicherlich kann man GnuCash weiterentwickeln, 
> in Bezug auf die Abbildung fachlicher Anforderungen und in Bezug auf das 
> Anwendungsdesign. Was aber sind die Rahmenbedingungen, d.h. die Ziele und 
> Visionen? 

Visionen? In einem Open-Source-Projekt? (Wie war das mit Helmut Schmidt 
http://www.google.com/search?q=visionen+soll+zum+arzt) Die sind so eine 
Sache. Dabei hilft selbst die schönste Vision nichts, wenn diejenigen, 
die sie formuliert und getragen haben, dann eh irgendwann wieder 
verschwinden. Auf http://www.gnucash.org/en/roadmap.phtml (das Dokument 
ist aus dem Jahr 2000) hat der ursprüngliche Initiator von gnucash, 
Linas Vepstas, seine Ideen ausgebreitet. Der ist aber schon länger weg. 
Seitdem hat niemand sonst eine Vision formuliert, so daß ich nur davon 
ausgehen würde, daß halt jeder aktive Developer so sein eigenes Ziel 
verfolgt. (In meinem Fall ist das "eine deutsche Finanzverwaltung für 
den Heimanwender" mit Homebanking und bunten Bildern, und an beidem hab 
ich maßgeblich mitgewirkt http://www.gnucash.org/en/history.phtml und 
habe da ein Auge drauf.)

Die angefragten/vorgeschlagenen Änderungen für weitere deutsche 
Geschäfts-Features dagegen würden wieder "eine neue Vision" dafür 
benötigen und vor allem 1-2 Leute, die dieses eben auch wirklich tragen 
und umsetzen wollen. Solange es das nicht gibt, kann man die 
strukturellen Änderungen zwar denken, aber muß sich dann eine Lösung 
ohne deren Verfügbarkeit aus den Fingern saugen.

> Die Frage zu den Kontenplaenen ist nur ein Punkt. Das "Alles in einen Topf -- 
> eine Datenstruktur -- werfen"  schraenkt auch an anderen Stellen sowohl 
> funktional als auch in Bezug auf die Weiterentwicklung sehr ein. (...)

Natürlich. Ich hab ja nur den Ist-Zustand erläutert und wie er 
seinerzeit begründbar war. Ich verstehe deine prima Ausführungen also 
als Bestätigung, daß die grundsätzliche Struktur von Gnucash in einer 
einzigen Kontenhierarchie eine fundamentale Begrenzung für zukünftige 
Features ist.

> Soll der Funktionsumfang von GnuCash signifikant weiterentwickelt werden, wird 
> man um eine Modularisierung der beschriebenen Art sicher nicht umhinkommen. 

Es gibt eine Sorte von Modularisierung bereits im aktuellen 
GnuCash-Code: Verschiedene Teile der GUI können über einzelne Module 
eingebunden werden. Dadurch ist ja HBCI als extra Modul eingebunden. 
Aber die Speicherungsmöglichkeiten eines solchen externen Moduls sind 
nur rudimentär. Es fehlt also z.B. eine Modularisierung auf Datenebene, 
d.h. mehrere Bücher in einer Datei oder Datenbank. Ich will also nur 
darauf hinweisen, daß das Stichwort "Modularisierung" ziemlich allgemein 
ist und man das noch genauer schärfen müsste.

> Erst wenn die Ziele (und Visionen) formuliert und aufgeschrieben sind, und 
> wenn sie von einer hinreichenden Menge von engagierten Entwicklern und 
> Anwendern getragen werden, kann man eine Weiterentwicklung oder ein 
> (Re)design von GnuCash diskutieren, dass mit einer gewissen 
> Wahrscheinlichkeit nicht im Papierkorb (oder /dev/null) landen und die 
> Beteiligten frustrieren wird.

Genau. Deswegen erkläre ich hier wieder und wieder den Ist-Status von 
GnuCash, bis 1-2 Leute die Herausforderung annehmen und selber etwas 
Code in die Hand nehmen. Aber bis dahin ändert sich nix.

> Falls es hierzu etwas gibt, wuerde ich es gerne lesen (egal ob deutsch oder 
> englisch).

Es gibt das GNUe-Projekt 
http://www.gnu.org/software/gnue/project/what.html aber das geht auch 
nur schleppend voran. Zu gnucash gibt es den obigen uralten Text und 
sonst http://www.linuxwiki.de/GnuCash/DevelTexts und 
http://www.linuxwiki.de/GnuCash/WeiterEntwicklung

Christian