Das Haushaltsbuch - der Klassiker aus mehreren Jahrhunderten, um die Finanzen im Überblick zu behalten, zu analysieren und auf Grundlage von Wissen, nicht vom Glauben, fundierte Entscheidungen treffen zu können. Dabei handelt es sich, buchhalterisch gesehen, um eine einfache Eingaben- und Ausgaben-Gegenüberstellung. Die Geldbewegungen in einem solchen Buch kann sowohl das Bargeld, als auch diverse Bankkonten (Girokonto, Tagesgeld, Depot, etc.) umfassen.
Warum soll es dafür nicht ein Stück Software geben, dass den Prozess des Aufschreibens, Analysierens, etc. vereinfacht, damit man wieder mehr Zeit hat, sich den schönen Dingen des Lebens zu widmen? Laut meinem Kenntnisstand gibt es aktuell kein solches openSource Projekt. Selbstverständlich gibt es viele openSource ERP-Systeme auf dem Markt. Doch solche umfangreiche Software würde unsere anzusprechende Zielgruppe deutlich überfordern. Denn mit dem Projekt sollen hauptsächlich Privatpersonen angesprochen werden - mit der Skalierungsmöglichkeit hin zu Small-Office-Home-Office (SOHO).
Geplante Feature Übersicht
- Kosten normal per Dialog eintragen
- Definition regelmäßige Kosten und Umlage auf die jeweiligen Monate als Ausgabeposten (zum Beispiel Jahresgebühr Versicherungen, quartalsmäßige Kosten, etc.) mit Vorschau Funktion auf die errechnete Zukunft
- Möglichkeit die Kosten kategorisieren zu können
- Vorgabe von Standard-Kategorien und die Möglichkeit solche selbst zu definieren
- wünschenswert: Anbindung einer Bilderkennungssoftware, sodass Bilder von Belegen automatisch verbucht werden könnten. Also mögliche Bildquellen würde hierfür am PC ein Scanner dienen und am Smart Phone die Kamera. Die Erkennungsrate sollte hier hoch sein, weil es sich bei Belegen um Computer-Schrift handelt, nicht um handschriftliche Texte (in der Regel).
- Importer/ Exporter im XML Format, eventuell mit Verschlüsselung (wegen der Sensibilität der vorliegenden Daten)
- Verschlüsselung der Daten auf dem Speichermedium (wegen der eventuell vorliegenden Sensibilität der Daten)
Meine Ideen aus technischer Sicht zur Realisierung stichpunktartig zusammen gefasst
- Programmiersprache: Java. Damit lässt sich die Software Plattform-übergreifen entwickeln und eine Portierung auf mobile Endgeräte ist ohne große Hürden möglich
- Persistenz-Adapter Schnittstelle: Damit soll sichergestellt werden, dass die Speicher-Schicht nicht nur aus relationalen Datenbanksystemen bestehen kann, sondern eben auch aus Graph Datenbanken. Sofern vom Anwender nicht anders konfiguriert, soll eine sqlite Datenbank im Hintergrund werkeln.
- Als GUI soll Java Spring dienen - es wird kein eigenes Java Look & Feel geben, außer es finden sich Freiwillige dafür
- Verwendung beziehungsweise Anbindung folgender openSource Komponenten:
- Hibernate als ORM-Framework für relationale Datenbanken
- Neo4J als Java Treiber direkt unter der oben erwähnten Adapter-Schnittstelle
- C Bilderkennungssoftware (Anbindung dann mittels JNI Schnittstelle)
- das Java Projekt selbst eventuell als Maven Projekt anlegen, damit das Abhängigkeiten-Handling zum Kinderspiel wird
- JUnit als Unit-Test-Framework
- Log4J für RFC konformes Logging von auftretenden Laufzeit-Fehlern und nicht gefangenen Ausnahmen
- openSource Komponente, mit der man direkt aus der App heraus eine Smart Phone Kamera ansteuern kann und Fotos von Belegen schießen kann - eventuell auch denkbar als Fernsteuerung der vorhandenen Kamera-Software auf dem Smart Phone
- als Kollaborationsplattform würde ich GitHub, SourceForge oder Bitbucket empfehlen. Vor allem wegen dem Ticket-System, der Versionsverwaltung git, sowie der Möglichkeit der Verwendung von Build Servern (continues CI)
- als git Braching-Strategie würde ich die der Release-Branches empfehlen: Die Hauptentwicklung findet im master Branch statt, Meilensteine der Software spalten sich vom master Branch zum Zeitpunkt X ab und werden nie wieder zurück in den master Branch geführt, Sicherheitsrelevante Patches werden händisch als jeweils eigenen Commit auf den Vorgänger-Release Branches nachgepflegt.
- Projektname: Cashbook (der Projektname kann natürlich jederzeit geändert werden, sollte uns ein besserer Name einfallen. Jedoch brauchen wir intern einen, um mit der Entwicklung starten zu können.)
Ich würde mich als federführender Entwickler und Projekthauptverantwortlicher freiwillig melden. Jedoch werde ich wenig Zeit haben am Projekt aktiv mit entwickeln zu können. Ich werde meinen Teil als Chefentwickler dazu beitragen, sowie mich um die Verwaltung der Infrastruktur kümmern und von Zeit zu Zeit Pull Requests prüfen.
Als Lizenzmodell, damit das Projekt möglichst viel Verbreitung auf der Welt findet, würde ich die MIT Lizenz vorschlagen.
Bitte teilt mir doch eure Meinung dazu in den Kommentaren mit. Sehr gerne dürfen sich auch freiwillige Mitstreiter in den Kommentaren melden, die gemeinsam Projekt mit arbeiten wollen. Für eine derartige Projektgröße werden viele unterschiedliche Entwickler, Übersetzer, (UX-)Designer, etc. benötigt. Scheut also bitte nicht davor, euch zu melden - jeder ist im Team willkommen, egal wie groß oder klein der Beitrag sein mag :-)