Demoweek: Webseitentext
===

###### tags: DemoWeek
Ihr veröffentlicht einen Text über das Ziel, die Entstehung und andere interessante Aspekte eures Projekts oder Erkenntnisse aus der Förderphase.

> FabAccess Projekt Thumbnail

# Das Projekt
Wir entwickeln FabAccess, ein föderierbares Verwaltungssystem für FabLabs, Makerspaces und Hackerspaces. Mit FabAccess soll der Zugriff auf Maschinen verwaltet werden, um so Unfälle zu vermeiden.

# Das Team
> TODO: Teammitglieder verstellen

# Das Problem
Viele Hacker und Maker haben sich schon mit der Herausforderung befasst ein eigenes FabLab nach den Vorstellungen von Neil Gershenfeld aufzubauen und dieses mit wenig Personal "sicher" zu betreiben.
Um das möglich zumachen haben diese auch angefangen eine Verwaltungssoftware für ihre eigenen Spaces zu schreiben.
Auch wir standen vor der Herausforderung: Wie kann man "gefährliche" Maschinen, wie unsere alte Drehbank, sicher betreiben? Gleichzeitig sollte natürlich die Idee des eigenständigen Lernens im FabLab erhalten bleiben, ohne dass ständig 20 Angestellte Jedem beim Umgang mit solchen Maschinen über die Schulter schauen müssen. Somit war die Idee für unsere Projekt FabAccess geboren.

Aber das ist noch nicht alles was FabAccess ausmacht. Durch den doch sehr begrenzten Platz in unserem Labor ist es uns nicht möglich jede Maschine unseren Nutzern zur Verfügung stellen zu können.
Wie können wir es also unseren Nutzern ermöglichen, unkompliziert an andere Maschinen zu kommen und gleichzeitig so wenig wie möglich Mehraufwand bei kooperierenden Spaces zu erzeugen.
Mit diesem Problem ergibt sich der zweite wichtige Aspekt von FabAccess, denn FabAccess ist ein föderierbares Verwaltungssystem. Somit können sich Spaces aller Art zusammenschließen und die Nutzer können je nach Makerproblem den passenden Space besuchen. So wird die Kommunikation und Zusammenarbeit zwischen allen gestärkt. Aus Kommunikation entsteht bekanntlich Innovation.

# Die Ausgangslage
Da wir Kommunikation fördern wollen, haben wir zu Beginn des Projektes auch genau dort angefangen. Um möglichst allen Bedürfnissen und Wünschen, die aus vielen Perspektiven an ein solches Verwaltungssystem gestellt werden, gerecht zu werden, haben wir uns auf FabLab- und Makerkonferenzen umgehört und sind aktiv auf die verschiedensten Creator(Nutzer eines Spaces) und Manager(Betreiber eines Spaces) solcher Spaces zugegangen. Mit diesen gemeinsam haben wir uns in kleinen und mittleren Runden zusammengesetzt, um all die Ideen zusammenzuschreiben.

Natürlich dachten wir uns schon, dass wir nicht die Ersten sind, die sich an ein solches Projekt wagen. Daher haben wir nach guter OpenSource-Arbeitsweise, nach solchen Projekten gesucht, gefragt und sind auch dort aktiv auf die Beteiligten zugegangen.
Die Projekte waren auf den verschiedenesten Ständen, von einfachen Frontend-Designs bis hin zu lokal verwendeten Systemen. Um nicht auf dem Stand von "works for me" zu bleiben, haben wir uns mit den Entwicklern solcher Systeme getroffen und uns über die Umsetzung und "Lessons Learned" unterhalten, gechattet, gemeetet und offen diskutiert.

Die vielen Anregungen aus diesen Runden haben wir in einem Lastenheft kondensiert und festgehalten. Dieses Lastenheft bildet die Grundlage für unser Projekt, auch wenn wir in unserer Arbeitsweise nicht im klassischen [Wasserfallmodell](https://de.wikipedia.org/wiki/Wasserfallmodell) geblieben sind. Selbstverständlich haben wir flexibel und teilweise mit agilen Konzepten gearbeitet haben.

Da all diese Projekte nur lokal im Einsatz waren und wir einen föderativen Ansatz verfolgten (der "Verband offener Werkstätten" war an diesem Wunsch nicht ganz unbeteiligt) mussten wir dort gezielt ansetzen. Daraufhin haben wir uns auf die Förderung des Prototype Fund beworben, um uns in der Förderphase voll auf die Planung und Entwicklung dieses Projekts konzentrieren zu können.

Liste von bekannten Projekten ähnlicher Zielrichtung:
* [Commons Booking](https://prototypefund.de/project/commons-booking/)
* [Fab Lab Siegen (David Amend)](https://github.com/FabLabSiegen/FabLabAccessControl)
* [Düsseldorf (Fabian Meyer)](https://github.com/faaaaabi/)
* Beuth Hochschule für Technik Berlin
* [qrhello](https://github.com/dequbed/qrhello)
* [card2go](https://github.com/HazeCore/Card2Go/)
* [ETH Zürich](https://sph.ethz.ch/acos_project/)
* [Übersicht beim Verband offener Werkstätten](https://cowiki.offene-werkstaetten.org/uploads/2017-06-23_11-31-15_Zugangssysteme%20%C3%9Cberblick%20(WS).pdf)
* [FabLab L'Aquila](https://github.com/FabLabAQ/LabAccessControl)
* [Google makerspace-auth](https://github.com/google/makerspace-auth)
* [Dresden (Roseguarden)](https://github.com/mdrobisch/roseguarden)
* [FabLab München](https://github.com/sschaeffner/)
* [MakerSpace Graz ("LEASIE")](https://leasie.makerspace.at/)
* [Hackerspace Liege](https://github.com/LgHS/sign-in)
* [Flipdot e.V. Kassel](https://github.com/flipdot/gsm-door)
* [CoreDump, Rapperswil-Jona / Schweiz](https://github.com/coredump-ch/interna)
* [open-taffeta](https://github.com/apiraino/)

# Die Umsetzung
Da wir zu unseren Features und Plänen schon ein paar kleine Vorträge gehalten haben, sowie vieles auf unserer Webseite niedergeschrieben ist, verlinken wir an dieser Stelle dorthin. Schaut es euch gerne an.

---

**FabAccess Feature Beschreibung:** [fab-access.org](https://fab-access.org/de/projects/fabaccess/)

**FabAccess Feature- und Planungsvortrag vom rC3:** [media.ccc.de](https://media.ccc.de/v/rc3-326175-fabaccess)

**Folien vom rC3 Vortrag:** [docs.google.com](https://docs.google.com/presentation/d/1Lk1l-6z8GM2PyjsHXDBPsHLr4PJJ27CuA3QnHiB23cM/edit?usp=sharing)

---
**tl;dr:**
FabAccess besitzt drei Hauptfunktionalitäten:
* Maschinenverwaltung
* Berechtigungssystem
* Nutzerverwaltung

Das Prinzip von FabAccess ist es, Maschinen über den Stromanschluss ein- und auszuschalten. So sind Maschinen im Normalfall stromlos und damit ungefährlich. Erst wenn Nutzer an der Maschine sind, die für die sichere Bedienung befähigt und eingewiesen sind, wird die Maschine mit dem Stromnetz verbunden.

**Warning**
Wir werden in dem weiteren Text mehr auf die Projektumsetzung und die Prototype Fund Förderung eingehen, da wir die Features schon ausführlicher und besser in den Beiträgen erklärt haben.

## Tooling
Jedes Team braucht ein sinnvolles Tooling, die Frage ist nur, was heißt "sinnvoll"? (yeah!! - Tooldiskussionen!!)
Der Ansatz für unser Tooling basiert, wie bei den meisten Projekten, auf den vorhandenen Fähigkeiten der Entwickler.
Um einen möglichst stabilen Core zu entwickeln wird unsere Server in Rust entwickelt, da wir einen sehr guten Rustentwickler an Bord haben. Die Sprache ist auch gut für die Entwicklung stabiler Backends geeignet, weil viele Programmierfehler schon durch den relativ intelligenten Compiler verhindert werden.

Für das Frontend war es die "Wahl der Qual", welche Plattformen will man unterstützen und mit welchem Framework kann man unsere Ideen überhaupt umsetzen.
Unsere Wahl ist aufgrund der kurzen Förderphase auf C# mit Xamarin gefallen, da einer von uns schon etwas Erfahrung mit WPF-Entwicklung hatte und sich mit Hilfe von Xamarin ein Client gut auf fast alle Plattformen portieren lässt.

Für eine funktionierende und langfristige Föderation benötigten wir eine stabile API, über die die einzelnen Instanzen und Clients mit unserem Server(BFFH - Diflouroborane) kommunizieren können. Auch eine Abwärtskompatibilität ist sinnvoll, wenn BFFH von einzelnen Spaces auf deren Bedürfnisse angepasst werden können soll. Dabei sollte unser Referenzclient (Borepin) nicht funktionsunfähig werden. Um all dies möglich zu machen, ist unsere API in Cap'n Proto geschrieben.

> Struktur von FabAccess, mit Schnittstellenaufteilung

## Erweiterungen
Dieses Thema war bei Gesprächen mit den anderen Spaces immer vorne mit dabei, da keiner der Spaces seine selbst gebaute Hardware neu bauen will oder teuer eingekaufte Systeme verlieren möchte. Um das möglich zu machen, haben wir eine API geplant, die generisch genug ist um verschiedenste Systeme anzubinden.
Damit nicht jeder Space seine Hardware selbst basteln muss und damit zum Entwickeln eigener Software gezwungen wird, entwickeln wir von unserer Seite aus passende Referenzhardware um den Einstig zu erleichtern.
Um die kommerziellen Produkte nicht außer Acht zu lassen, arbeiten wir an der Einbindung der gängigsten Geräte, wie Shelly Plugs oder Systeme mit Tasmota und anderen. Somit kann sich ein Space beim Verwenden unseres Systems entweder unserer Bastelaufgabe stellen oder einen schnellen Einstieg durch gekaufte Produkte hinlegen.

## Hardware
An der Hardware haben wir durch die Bindung der Förderung leider nicht so viel arbeiten können, aber wir haben einen sehr engagierten Unterstützter gefunden (Vielen Dank an dieser Stelle an Joris), der für uns den ersten Prototypen eines SmartCard-Readers entwickelt hat, der sich schon wunderbar an unsere Schnittstellen anbindet.
Für weitere Hardware zum Schalten haben wir schon vor der Förderphase eine Gruppe aus der Schweiz gefunden, die mit uns bei diesem Vorhaben zusammenarbeitet.

Also erstmal noch ein kleines "coming soon".

> Drehbank mit erstem Schaltungsprototypen

## SmartCards
Einen SmartCard-Reader benötigen wir durch den Wunsch Maschinen mit einer SmartCard zu aktivieren und nicht nur über ein Handy oder einen PC. Dieses Feature war bei der Planung nicht vollständig in seiner Komplexität zu erfassen. Es gibt einige gute Open Source Libraries, mit denen sich so gut wie alle auf dem Markt befindlichen SmartCards lesen und beschreiben lassen. Die Frage, die wir uns in diesem Zusammenhang stellen mussten war, welche der Karten unterstützen wir und was sind unsere Anforderungen an eine SmartCard. In einem anderen Projekt werden NXP MIFARE Classic Karten verwendet. Da diese schon seit über 10 Jahren keinen ernstzunehmenden Schutz mehr gegen Clonen der Karten bieten, haben wir uns gegen eine solche Lösung entschieden. Die Anforderungen an ein föderierbar einsetzbares SmartCard-System sind hoch, da so die jeweils andere Partei keine einfache Validierung der Karte durchführen kann. Auch das Authentifizieren mit einem Schlüssel gestaltet sich über Föderationen hinweg schwierig, da der Reader dem einen Space gehört und die Karte dem anderen. Ein Reader hat daher nicht immer die Schlüssel für die gelesenen Karten.
Um das valide und nutzbar umzusetzen haben wir uns für eine kostengünstige Lösung, mit NXP Mifare DESFire Karten entschieden. Die Karte besitzt das Feature, dass sie OTA (Over-the-Air) mit entfernten Servern kommunizieren kann. Somit kann zwischen der Karte und dem Server direkt verschlüsselt kommunziert werden und der Reader spielt nur Proxy. Mit diesem Ansatz stellen wir ein sicher föderierbares Kartensystem, was wir so bisher noch nicht im OpenSource-Bereich finden konnten.

## Föderation
Nachdem wir die ganze Zeit von Föderation reden und schreiben wollen wir auch die Frage klären, was Föderation für uns ist.
Wir haben unseren Ansatz wie folgt definiert:
> Föderation ist eine Form von Zusammenarbeit von Organisationen. Die Organisationen behalten dabei ihre Eigenständigkeit und arbeiten gleichberechtigt und weitgehend autonom bei der Erreichung gemeinsamer Ziele zusammen.

Unser gemeinsames Ziel mit FabAccess ist das niederschwellige und unkomplizierte Teilen von Nutzern und somit die Verbesserung der Zusammenarbeit von Creatoren über Spacegrenzen hinweg, sowie die gleichberechtigte Zusammenarbeit von Managern.

Unser Ansatz kann in der Realität wie folgt aussehen:
Creator aus Space A geht zu Space B und kann dort mit der Einweisung für eine Maschine aus Space A die gleiche Maschine in Space B verwenden, ohne eine weitere Einweisung zu benötigen.

Wir haben gesammelt und wissen was die meisten anderen Projekte machen und gemacht haben. Zumindest innerhalb einer einzelnen Werkstatt. Allerdings gibt es verschiedene Dach-Organisationen, die diese Werkstätten als Verband gemeinsam vertreten.
Um föderieren zu können brauchen wir einen Standard, den alle nutzen können.
Also eine stabile API-Beschreibung und stabile Strukturen, die von den einzelnen Teilnehmern abwärtskompatibel erweitert werden können, ohne dass die ursprünglich implementierte Föderation gestört wird.

Um nicht auf eine spezielle Hardware angewiesen zu sein braucht es generische Schnittstellen, die komplexe und einfache Hardware unterstützen. Sicherheitsanforderungen sollen vorerst so weit das geht beim Anwender bleiben und nicht auf uns zurückfallen.

Was wir können (können wollen): Ein sicheres und stabiles Berechtigungssystem bieten, das die notwendige Kommunikation realisiert und Events an generische Schnittstellen geben kann.
Das System soll dabei granuliert und anwenderorientiert Entscheidungen weitergeben. Weiterhin soll es den Anwendern dienen und dabei nicht in deren Prozesse eingreifen oder ihnen ungewollte Komplexität oder Strukturen aufzwingen, oder gar in deren Entscheidungen einwirken.

Und dass unter den einzelnen Instanzen gemeinsame Entscheidungen mit Föderation getroffen werden können, ohne dass die einzelnen Parteien ihre Rechte verlieren.

# Die Herausforderungen
Auch wir standen während der Umsetzung vor einigen Herausforderungen, die Schwierigsten haben wir mal niedergeschrieben.

## Aller Anfang ist schwer
Da unser Projekt viele Aspekte und eine hohe Komplexität besitzt war das Auswählen schwierig. Wir konnten nicht direkt einzelene Features seperat bauen, da der Core erst implementiert werden musste, bevor wir mit solchen Funktionalitäten beginnen konnten.
Auf der Core-Seite begannen wir mit dem Aufbau eines Event-Netzwerks und der Anbindung von einem MQTT Server, sowie dem Aufbau der Datenbankstrukturen.
Auf der Client-Seite war die Auswahl für unabhängige Aufgaben begrenzt, da die Funktionalität im Core und über die Cap'n Proto API abgebildet wird. Daher stürzten wir uns auf die Implenetierung von dem SmartCard Proof-of-Concept und der Anbindung der Cap'n Proto API.

## Closed Source SmartCards
Die Möglichkeit für ein OTA-Verfahren, mit den DESFire Karten, haben wir einem Beispiel Dokument direkt von NXP entnommen. Zum Glück hat sich ein Entwickler schon mit der Implementierung eines solchen Verfahren beschäftigt und die nötigen Schritte in ein bisschen Python Code validiert und mit einer kurzen Beschreibung auf GitHub veröffentlicht. Auf der Suche nach NFC-Libraries stellt sich eine über ein Netzwerk aufgebaute Verbindung als nicht sehr verbreitet heraus und die Libraries waren alle so aufgebaut, direkt mit der Karte über einen Reader oder die von Windows bereitgestellt PC/SC (Personal Computer/Smart Card API) zu kommunizieren. Da wir die Kommunikation mit Karte vom BFFH aus durchführen müssten wir sowohl für C# als auch für Rust eine verwendbare Bibliothek finden.
Da sich keine passenden Library finden ließ, haben wir uns der Herausforderung gestellt und selber eine Klassenbibliothek in C# begonnen, die wir nach Rust porten wollten. Das stellte sich als schwerer heraus als gedacht, da die Dokumentation von der von uns verwendeten DESFire Karten unter einem NDA(Geheimhaltungsvertrag) steht und wir mit unserem Open Source Code diese Anforderungen nicht erfüllen können. An diesem Zeitpunkt begann für uns eine umfangreiche Recherche und Dokumentensammlung, wie die DESFire Karte funktioniert. Da die bekannten Libraries leider keine Kommunikationsbeispiele besitzten haben wir Tests für unsere Bibliothek aufgebaut, die genau einer reale Kommunikation mit der Karte entspricht. Mit diesen Tests können wir einfacher unseren Code in Rust testen.
Wir werden unsere Unterlagen dazu nach einer Aufarbeitung auch bei uns in einem eigenen GitLab-Projekt veröffentlichen. Da wir anderen Entwicklern die Arbeit mit diesen Karten vereinfachen möchten.

## UX und NFC
In unserem ersten Coaching, mit SimpleSecure stellten wir unseren ersten Designentwurf für Borepin vor. Bei diesem Gespräch stellt sich heraus, dass wir an dem Wiedererkennungsmerkmal für eine NFC Interaktion kreieren sollten, um so Nutzern eine einfache Erkennung von NFC Tags oder Karten bereitzustellen. Somit ist unser Design für eine NFC Markierung entstanden.

> SmartCard und Maschinensticker im FabAccess NFC Design

## Föderation und Netzwerke
Bei der Föderationsplanung und -entwicklung hatten wir ein paar ungeklärte Fragen zu beantworten.
Da unser langfristiges Ziel ist über eine Föderation auch ein Abrechnung zu ermöglichen sollten die Föderationsabläufe sicher und nachvollziehbar für beide Partein sein.
Da Föderation für beide Seiten ein Vorteil mit sich bringen muss, sind bisher die Planung von unserer Seite nur eine direkte Föderation zu erlauben. Somit föderieren nur Spaces miteinandern, wo sich die Manager kennen und zusammenarbeiten wollen. Es ist keine Netzwerkbildung möglich, bei der ein Zusammenschluss von Spaces entsteht, bei dem ein neuer Spaces direkt Zugriff alle Space bekommt ohne diese selbstständig und gegenseitig zu akzeptieren.
Diese Entscheidung hat viele Diskussionen mit sich gebracht, da wir aber auch keine rechtliche Grundlage sehen dort Berechtigungen auszutauschen halten wir diese Vorgehenweise in der aktuellen Position für die sinnvollste. Wir wollen ja auch die Kommunikation fördern, also warum sollten die Manager denn nicht, mit einander mal geredet haben.

## Community
Bei Thema Community und Unterstüzer netzwerken wir nun schon seit über zwei Jahren für diese Projektidee und haben uns auch in Laufe der Förderung, um eine Veröffentlichung unser Fortschritte bemüht.

Um unsere Kommunikation für die Entwicklung des Projekts nicht in privaten Chatgruppe zuführen haben wir uns für die Open Source Software Zulip entschieden und sind dort für neue und alte Interessierte und Unterstützer leicht erreichbar. Und das Threading ist in Zulip für ein solches Projekt ideal, um hier mal ein bisschen Werbung zumachen.

Durch die Verbindung unser Teammitglieder zum Chaosumfeld haben wir unseren ersten Vortrag beim Chaostreff Potsdam, anfang Dezember, gehalten. Das war zwar bei uns noch nicht so geplant hatte sich aber durch ein Missverständnis so ergeben. In diesem konnten wir unser Projekt vorstellen und die ersten Erkenntnisse und Planungen vorstellen. Vielen Dank an dieser Stelle an den Chaostreff Potsdam.

Da es nun schon fast Tradition ist auf dem Chaos Communication Congress eine kleine Gesprächsrunde rund um das Thema FabLab zuführen haben wir uns für eine digitale Gesprächsrunde auf dem rC3 entschieden.
Durch diesen Talk konnten wir unserem Projekt zu mehr Öffentlichkeit verhelfen. Auch die Make hat uns darauf hin in einem ihrer Online Artikel erwähnt, sowie ein Beitrag in der aktuellen Ausgabe veröffentlicht.
Dieses mediale Interesse, sowie die Rückmeldungen haben uns gezeigt, dass wir auf einem guten Weg sind und unser Projekt etwas verändern könnte.

# Der Stand
Wie leider so oft in durchgeplanten Projekten haben wir **nicht alle** Ziele schon am Ende des Förderzeitraums erreicht.

Wir haben wie ihr in dem Video gesehen habt einen Prototypen der Maschinen einschalten kann.

Das SmartCard-System haben wir bisher nur als Code Libraries und Proof-of-Concept vorliegen, es muss noch in den Core eingearbeitet werden.

Wir haben eine erste Version der API am Anfang des Projektes definiert, welche grundlegende Funktionen beinhaltet hat die wir zu diesem Zeitpunkt schon festlegen konnten. Wir arbeiten gerade an einer verbesserten Version in die unsere jetzigen Kenntnisse und zukünftigen Wünsche einfließen, um bald einen stabilen Stand bieten zu können. Auch die einzelenen Subsysteme die wir definiert haben werden jetzt dort eingearbeitet.

Auf der Seite des Clients gibt es noch einige Bugs zu fixen, um unseren Cap'n Proto Code auf allen Plattformen ausführen zu können.
Auch müssen wir unsere Designs noch in den Client einbauen, das ist der nächste Schritt nach der API Verbesserung.

Auch muss unsere komplette Planung noch genauer aufgeschrieben werden und unsere Konzept-Entscheidungen festgehalten werden.

Für die Föderierbarkeit müssen noch ein paar Umsetzungsentscheidungen getroffen werden, dass wir dann auch alles in die API einfließen lassen können.

Wie ihr seht haben wir noch einiges zu tun.

# Die Zukunft
Die gute Nachricht ist, **wir machen weiter**.

Wir arbeiten an einer Strategie zur weiteren Förderung unseres Föderationskonzepts, um das gemeinsam mit dem Verband offener Werkstätten und dem Fab:Universe-Netzwerk fertigstellen zu können, um ab der zweiten Hälfte des Jahres ein größeres Rollout angehen zu können.

Auch wollen wir in einem Machbarkeitstest unseren Core (BFFH) erweitern und so testen, ob wir auch andere Anwendungen wie z.B. ein Netzwerk aus Lastenfahrradverleihen mit unserem System unterstützen können.
Unser offener und generischer Ansatz scheint sich auszuzahlen.

> Föderationsablaufbeispiel von FabAccess/DEMOKrAtIS
> *DEMOKrAtIS ist der Projektname des Machbarkeitsprojektes*

Mit unseren Verbündeten aus der Schweiz werden wir auch weiter zusammenarbeiten und bekommen mit etwas Glück aus der Richtung auch noch zwei Entwickler\*innen als Unterstützung.

Auch an der Hardwarefront wird weiter getüftelt, mit unserem Unterstützer wollen wir eine neue Version des Readers erarbeiten, die wir als OpenHardware und als Bausatz bereitstellen wollen.

Zu dem Thema Abrechnungssystem sind wir noch auf der Suche nach einem Partner mit dem wir als Open Source Lösung den FabLabs, Makerspaces und Hackerspaces bei der Abrechnung von Leistungen helfen können.

Wie ihr sehen könnt, haben wir noch einige Ideen und Visionen, an denen wir arbeiten können. Und wir bleiben unserem Motto vom Kickoff der Förderphase treu "3 Billion Devices run FabAccess".

Für alle die noch schöne Ideen für unser Projekt haben oder uns bei der Umsetzung (auch bei unseren anderen Fab... Projekten) helfen wollen, können wir nur sagen, kommt auf unser Zulip, **wir machen was Schönes draus**.

# Ein kleines Fazit
## Vom Projekt
Wir setzten mit diesem Projekt unseren Wunsch nach einer zusammenarbeitenden Open Source Gesellschaft um.

Leider waren auch wir durch die Corona Pandemie gebremst und auch einige Projektkontakte sind im Sande verlaufen. An der Stelle: Das war in keinem Fall Absicht!! - meldet euch einfach wieder bei uns, wenn ihr Zeit und Lust habt. Wir freuen uns über jeden der mit macht. Im großen und ganzen haben wir das Beste aus der geförderten Zeit gemacht.

Wir haben mehr Zeit in einige Aufgaben gesteckt als wir erwartet und geplant hatten. Mit den Ergebnissen können wir aber zufrieden sein. Wir sind unserem Ziel und der ursprünglichen Idee ein großes Stück näher gekommen.

Wir müssen aber auch zugeben, dass wir an unserem Teammanagment arbeiten müssen, die nicht vollsynchrone Arbeitsweise mit nur wenigen persönlichen Treffen in der Gruppe bringt einige Schwierigkeiten mit sich und kann schnell zu Spannungen führen.

## Von der Prototype Fund Förderung
Die Förderung durch den Protoype Fund hat unserem Projekt einen riesigen Sprung nach vorne verschafft.
Ohne die Möglichkeit, viel Zeit in Planung und Entwicklung stecken zu können und dabei trotzdem unseren diversen finanziellen Verpflichtungen nachkommen zu können, wären wir nie in dem halben Jahr auf das Level gekommen, auf dem wir jetzt sind.

Die Organisation vom Prototype Fund ist gut, wir würden uns aber noch mehr Unterstützung bei den steuerlichen und finanziellen Aspekten der Förderung wünschen. Die Coachings waren sehr hilfreich für die Design Entscheidungen, für die wir auch schon viel Lob bekommen haben, vielen Dank an Eileen und Simply Secure an dieser Stelle.

Wir hoffen, dass das BMBF auch in Zukunft solche Civic Tech Projekte unterstützt und so einen Startboost gibt.

Vielen Dank auch an das Team vom Prototype Fund für die Planung und Unterstützung bei dieser Förderung.