Stummel Erik Gfesser, Hauptarchitekt für die Datenpraxis von SPR – Interviewreihe – Unite.AI
Vernetzen Sie sich mit uns

Interviews

Erik Gfesser, Hauptarchitekt für die Datenpraxis von SPR – Interviewreihe

mm
Aktualisiert on

Erik trat der Datenpraxis von bei SPR's Emerging Technology Group als Hauptarchitekt im Jahr 2018.

Erik spezialisierte sich auf Daten, Open-Source-Entwicklung mit Java und praktische Unternehmensarchitektur, einschließlich der Erstellung von PoCs, Prototypen und MVPs.

Was hat Sie ursprünglich am maschinellen Lernen gereizt?

Es ermöglicht Anwendungen, kontinuierlich zu lernen. Ich hatte meine Entwicklungskarriere als leitender Datenanalyst mit SPSS bei einem späteren globalen Marktforschungsunternehmen begonnen und später die Verwendung einer Geschäftsregel-Engine namens Drools in Anwendungen integriert, die ich für Kunden erstellt habe, aber das Ergebnis all dieser Arbeit war im Wesentlichen statisch.

Später absolvierte ich eine Prozessverbesserungsschulung, bei der die Ausbilder detailliert demonstrierten, wie sie mithilfe von Statistiken und anderen Methoden die Geschäftsprozesse ihrer Kunden verbessern konnten, aber auch hier konzentrierte sich der Output weitgehend auf Zeitpunkte. Meine Erfahrung bei der Verbesserung eines Gesundheitsprodukts, das meine Kollegen und ich im gleichen Zeitraum entwickelt haben, hat mir gezeigt, warum kontinuierliches Lernen für solche Bemühungen notwendig ist, aber die jetzt verfügbaren Ressourcen gab es damals noch nicht.

Interessanterweise hat sich der Kreis meiner Faszination für maschinelles Lernen geschlossen, als mein Studienberater mich wegen des damaligen KI-Winters vor einer Spezialisierung auf das, was man damals künstliche Intelligenz nannte, warnte. Ich entscheide mich stattdessen dafür, Begriffe wie ML zu verwenden, weil diese weniger Konnotationen haben und weil sogar AWS anerkennt, dass seine KI-Services-Schicht eigentlich nur eine Abstraktion auf höherer Ebene ist, die auf seiner ML-Services-Schicht aufbaut. Während ein Teil des ML-Hypes unrealistisch ist, bietet es aus der Sicht der Entwickler leistungsstarke Möglichkeiten, solange dieselben Praktiker die Tatsache anerkennen, dass der Wert, den ML bietet, nur so gut ist wie die von ihm verarbeiteten Daten.

 

Sie sind ein großer Befürworter von Open Source. Können Sie uns erläutern, warum Open Source so wichtig ist?

Ein Aspekt von Open Source, den ich Führungskräften im Laufe der Jahre erklären musste, ist, dass der Hauptvorteil von Open Source nicht darin besteht, dass die Nutzung solcher Software ohne finanzielle Kosten möglich ist, sondern darin, dass der Quellcode frei verfügbar ist.

Darüber hinaus können Entwickler, die diesen Quellcode verwenden, ihn für ihre eigene Verwendung ändern. Wenn vorgeschlagene Änderungen genehmigt werden, können sie diese Änderungen anderen Entwicklern, die ihn verwenden, zur Verfügung stellen. Tatsächlich begann die Bewegung hinter Open-Source-Software dadurch, dass Entwickler lange darauf warteten, dass kommerzielle Firmen Änderungen an den von ihnen lizenzierten Produkten vornahmen. Daher machten es sich die Entwickler zur Aufgabe, Software mit der gleichen Funktionalität zu schreiben und sie so für Verbesserungen durch andere zu öffnen Entwickler.

Kommerzialisierung von Open Source macht sich diese Vorteile zunutze. Die Realität ist, dass viele moderne Produkte Open Source unter dem Deckmantel nutzen, auch wenn kommerzielle Varianten solcher Software typischerweise zusätzliche Komponenten bereitstellen, die nicht als Teil einer bestimmten Open Source-Version verfügbar sind, und so Unterscheidungsmerkmale bieten sowie Unterstützung, wenn diese benötigt wird.

Meine ersten Erfahrungen mit Open Source machte ich beim Aufbau des Gesundheitsprodukts, das ich zuvor erwähnt habe. Dabei nutzte ich Tools wie Apache Ant, das zum Erstellen von Software verwendet wurde, und ein frühes DevOps-Produkt namens Hudson (aus dessen Codebasis später Jenkins wurde). ). Der Hauptgrund für unsere Entscheidung, diese Open-Source-Produkte zu verwenden, war, dass diese entweder bessere Lösungen als kommerzielle Alternativen boten oder innovative Lösungen waren, die nicht einmal von kommerziellen Unternehmen angeboten wurden, ganz zu schweigen von der kommerziellen Lizenzierung einiger der von uns verwendeten Produkte war zu restriktiv und führte aufgrund der damit verbundenen Kosten zu einem übermäßigen bürokratischen Aufwand, wenn es darum ging, weitere Lizenzen zu benötigen.

Im Laufe der Zeit habe ich gesehen, wie sich Open-Source-Angebote weiterentwickelten und dringend benötigte Innovationen lieferten. Beispielsweise wurden viele der Probleme, mit denen meine Kollegen und ich beim Aufbau dieses Gesundheitsprodukts zu kämpfen hatten, später durch ein innovatives Open-Source-Java-Produkt namens Spring Framework gelöst, das wir nach mehr als einem Jahrzehnt immer noch erfolgreich nutzen und dessen Ökosystem geht mittlerweile weit über einige der ursprünglich bereitgestellten Innovationen hinaus, die heute als alltäglich angesehen werden, wie etwa die Abhängigkeitsinjektion.

 

Sie haben Open Source für die Erstellung von PoCs, Prototypen und MVPs verwendet. Könnten Sie Ihre Reise hinter einigen dieser Produkte erzählen?

Wie in einem der Leitprinzipien erläutert, die ich kürzlich einem Kunden vorgestellt habe, sollten Ausbauten für die Datenplattform, die wir für ihn erstellt haben, im Laufe der Zeit weiterhin iterativ und nach Bedarf durchgeführt werden. Es ist nicht zu erwarten, dass die für diese Plattform entwickelten Komponenten statisch bleiben, da sich die Anforderungen ändern und im Laufe der Zeit neue Komponenten und Komponentenfunktionen verfügbar gemacht werden.

Beginnen Sie beim Aufbau der Plattformfunktionalität immer mit dem minimal Realisierbaren, bevor Sie unnötigen Schnickschnack hinzufügen, der in manchen Fällen sogar die Konfiguration umfasst. Beginnen Sie mit dem Funktionalen, stellen Sie sicher, dass Sie es verstehen, und entwickeln Sie es dann weiter. Verschwenden Sie keine Zeit und kein Geld damit, Dinge zu bauen, bei denen die Wahrscheinlichkeit einer Nutzung gering ist, sondern bemühen Sie sich, künftigen Anforderungen gerecht zu werden.

Das MVP, das wir für dieses Produkt erstellt haben, musste ausdrücklich so erstellt werden, dass weiterhin weitere Anwendungsfälle darauf aufgebaut werden können, auch wenn es mit der Implementierung eines einzelnen Anwendungsfalls zur Erkennung von Kostenanomalien geliefert wurde. Im Gegensatz zu diesem Kunden hatte ein früheres Produkt, das ich gebaut habe, vor meiner Ankunft eine gewisse Geschichte. In diesem Fall diskutierten die Beteiligten drei Jahre lang (!) darüber, wie sie an das Produkt herangehen sollten, das sie entwickeln wollten. Ein Kundenmanager erklärte, einer der Gründe, warum er mich engagiert habe, sei, dem Unternehmen dabei zu helfen, einige dieser internen Debatten zu überwinden, insbesondere weil das Produkt, das er entwickeln wollte, der Hierarchie der beteiligten Organisationen gerecht werden müsse.

Ich kam zu dem Schluss, dass diese Grabenkämpfe größtenteils mit den Daten des Kunden, seiner Tochtergesellschaften und seiner externen Kunden in Zusammenhang standen. In diesem Fall drehte sich also das gesamte Produkt-Backlog darum, wie diese Daten aufgenommen, gespeichert, gesichert und genutzt werden würden für einen einzelnen Anwendungsfall, der spontan Netzwerke von Gesundheitsdienstleistern für Kostenanalysen generiert.

Zu Beginn meiner Karriere wurde mir klar, dass eine architektonische Qualität namens „Benutzerfreundlichkeit“ nicht nur auf Endbenutzer beschränkt ist, sondern auch auf Softwareentwickler selbst. Der Grund dafür ist, dass der geschriebene Code ebenso nutzbar sein muss wie Benutzeroberflächen, die für Endbenutzer nutzbar sein müssen. Damit ein Produkt nutzbar wird, müssen Proofs of Concept erstellt werden, um zu zeigen, dass Entwickler in der Lage sein werden, das zu tun, was sie sich vorgenommen haben, insbesondere wenn es um die spezifischen Technologieentscheidungen geht, die sie treffen. Aber Konzeptnachweise sind erst der Anfang, denn Produkte sind dann am besten, wenn sie im Laufe der Zeit weiterentwickelt werden. Meiner Meinung nach sollte die Grundlage für ein MVP jedoch idealerweise auf Prototypen basieren, die eine gewisse Stabilität aufweisen, damit Entwickler es weiterentwickeln können.

 

Während Rezension des Buches „Machine Learning at Enterprise Scale“ Sie haben erklärt, dass „die Verwendung von Open-Source-Produkten, Frameworks und Sprachen zusammen mit einer agilen Architektur, die aus einer Mischung aus Open-Source- und kommerziellen Komponenten besteht, die Flexibilität bietet, die viele Unternehmen benötigen, aber nicht sofort erkennen.“ Könnten Sie bitte näher darauf eingehen, warum Sie glauben, dass Unternehmen, die Open Source verwenden, flexibler sind?

Viele kommerzielle Datenprodukte nutzen im Verborgenen wichtige Open-Source-Komponenten und ermöglichen Entwicklern die Verwendung gängiger Programmiersprachen wie Python. Die Firmen, die diese Produkte entwickeln, wissen, dass die von ihnen ausgewählten Open-Source-Komponenten ihnen einen Starthilfe geben, wenn diese bereits in der Community weit verbreitet sind.

Open-Source-Komponenten mit starken Communities lassen sich aufgrund der Vertrautheit, die sie mit sich bringen, leichter verkaufen. Kommerziell erhältliche Produkte, die hauptsächlich aus Closed-Source-Produkten bestehen oder sogar aus Open-Source-Produkten bestehen, die größtenteils nur von bestimmten kommerziellen Produkten verwendet werden, erfordern häufig entweder eine Schulung durch diese Anbieter oder Lizenzen, um die Software nutzen zu können.

Darüber hinaus wird die Dokumentation für solche Komponenten größtenteils nicht öffentlich zugänglich gemacht, was dazu führt, dass Entwickler weiterhin von diesen Firmen abhängig sind. Wenn weithin akzeptierte Open-Source-Komponenten wie Apache Spark im Mittelpunkt stehen, wie bei Produkten wie der Unified Analytics Platform von Databricks, sind viele dieser Elemente bereits in der Community verfügbar, wodurch die Teile, auf die Entwicklungsteams von kommerziellen Einheiten abhängig sein müssen, minimiert werden ihre Arbeit zu tun.

Da Komponenten wie Apache Spark allgemein als De-facto-Industriestandardtools akzeptiert werden, kann Code außerdem einfacher in kommerzielle Implementierungen solcher Produkte migriert werden. Firmen werden immer geneigt sein, das zu integrieren, was sie als Wettbewerbsvorteile betrachten, aber viele Entwickler möchten keine Produkte verwenden, die völlig neu sind, weil sich dies als schwierig erweist, zwischen Firmen zu wechseln, und dazu neigt, ihre Bindungen zu den starken Communities, denen sie angehören, zu kappen zu erwarten.

Aus persönlicher Erfahrung habe ich in der Vergangenheit mit solchen Produkten gearbeitet und es kann schwierig sein, kompetente Unterstützung zu bekommen. Und das ist ironisch, wenn man bedenkt, dass solche Firmen ihre Produkte in der Erwartung des Kunden verkaufen, dass der Support zeitnah bereitgestellt wird. Ich habe die Erfahrung gemacht, eine Pull-Anfrage an ein Open-Source-Projekt zu senden, wobei der Fix noch am selben Tag in den Build integriert wurde, kann aber nicht dasselbe über ein kommerzielles Projekt sagen, an dem ich gearbeitet habe.

 

Sie glauben außerdem, dass Open Source „Zugang zu starken Entwicklergemeinschaften“ ermöglicht. Wie groß sind einige dieser Gemeinschaften und was macht sie so effektiv?

Entwicklergemeinschaften rund um ein bestimmtes Open-Source-Produkt können Hunderttausende erreichen. Die Akzeptanzraten sind nicht unbedingt ein Hinweis auf die Stärke der Gemeinschaft, sind aber ein guter Indikator dafür, da sie dazu neigen, positive Kreisläufe zu erzeugen. Ich halte Gemeinschaften für stark, wenn sie eine gesunde Diskussion und eine effektive Dokumentation hervorbringen und eine aktive Entwicklung stattfindet.

Wenn ein Architekt oder leitender Entwickler den Prozess durchläuft, um auszuwählen, welche Produkte er in sein Bauwerk integrieren möchte, spielen in der Regel viele Faktoren eine Rolle, nicht nur in Bezug auf das Produkt selbst und wie die Community aussieht, sondern auch in Bezug auf die Entwicklungsteams, die dies tun Welche Unternehmen werden diese übernehmen, ob sie gut zum zu entwickelnden Ökosystem passen, wie die Roadmap aussieht und ob in einigen Fällen kommerzielle Unterstützung gefunden werden kann, falls dies erforderlich sein könnte. Viele dieser Aspekte bleiben jedoch mangels starker Entwicklergemeinschaften auf der Strecke.

 

Sie haben Hunderte von Büchern auf Ihrer Website rezensiert. Gibt es drei, die Sie unseren Lesern empfehlen könnten?

Heutzutage lese ich nur sehr wenige Programmierbücher, und obwohl es Ausnahmen gibt, ist die Realität so, dass diese in der Regel sehr schnell veraltet sind und die Entwickler-Community in der Regel über Diskussionsforen und Dokumentation bessere Alternativen bereitstellt. Viele der Bücher, die ich derzeit lese, werden mir kostenlos zur Verfügung gestellt, entweder über Technologie-Newsletter, die ich abonniere, über Autoren und Publizisten, die sich an mich wenden, oder über die Bücher, die Amazon mir sendet. Zum Beispiel schickte mir Amazon für meine Rezension im Jahr 2011 einen unkorrigierten Probeabzug von „The Lean Startup“ vor der Veröffentlichung, der mich in das Konzept des MVP einführte, und schickte mir erst kürzlich ein Exemplar von „Julia for Beginners“.

(1) Ein Buch von O'Reilly, das ich empfohlen habe, ist „Auf der Suche nach dem Datenbank-Nirvana“. Der Autor behandelt ausführlich die Herausforderungen für eine Datenabfrage-Engine bei der Unterstützung von Arbeitslasten, die das Spektrum von OLTP auf der einen Seite bis hin zu Analysen auf der anderen Seite abdecken, mit Betriebs- und Business-Intelligence-Arbeitslasten in der Mitte. Dieses Buch kann als Leitfaden zur Bewertung einer Datenbank-Engine oder einer Kombination aus Abfrage- und Speicher-Engines verwendet werden, die auf die Erfüllung der eigenen Arbeitslastanforderungen ausgerichtet ist, unabhängig davon, ob diese transaktional, analytisch oder eine Mischung aus beiden sind. Darüber hinaus ist die Berichterstattung des Autors über das „schwingende Datenbankpendel“ der letzten Jahre besonders gut gelungen.

(2) Während sich im Datenbereich in den letzten Jahren viel verändert hat, da immer wieder neue Datenanalyseprodukte eingeführt werden, „Disruptive Analytics“ präsentiert eine leicht verständliche, kurze Geschichte der Innovationen in der Analytik der letzten 50 Jahre, die ich anderswo noch nicht gesehen habe, und erörtert zwei Arten von Störungen: disruptive Innovationen innerhalb der Analytics-Wertschöpfungskette und Branchenstörungen durch Innovationen in der Analytik. Aus der Sicht von Startups und Analytics-Praktikern wird der Erfolg dadurch ermöglicht, dass sie ihre Branchen revolutionieren, denn der Einsatz von Analytics zur Differenzierung eines Produkts ist eine Möglichkeit, ein disruptives Geschäftsmodell zu schaffen oder neue Märkte zu schaffen. Im Hinblick auf Investitionen in Analysetechnologie für ihre Unternehmen könnte eine abwartende Haltung sinnvoll sein, da Technologien, bei denen das Risiko einer Störung besteht, aufgrund der verkürzten Nutzungsdauer riskante Investitionen darstellen.

(3) Einer der besten Texte zum Technologiegeschäft, die ich gelesen habe, ist „Die Grenzen der Strategie„, von einem Mitbegründer des Research Board (von Gartner übernommen), einem internationalen Think Tank, der Entwicklungen in der Computerwelt und die Art und Weise untersucht, wie sich Unternehmen anpassen sollten. Der Autor präsentiert sehr detaillierte Notizen aus vielen seiner Gespräche mit Wirtschaftsführern und bietet durchweg eine aufschlussreiche Analyse seiner Erfahrungen beim Aufbau (mit seiner Frau) einer Gruppe von Kunden, großen Firmen, die ihre Strategien mit der explodierenden Welt der Informatik in Einklang bringen mussten. Wie ich in meiner Rezension anmerkte, unterscheidet sich dieses Buch von anderen verwandten Bemühungen durch zwei scheinbar gegensätzliche Merkmale: branchenweite Breite und Intimität, die nur durch persönliche Interaktion möglich ist.

 

Sie sind der Hauptarchitekt für die Datenpraxis von SPR. Können Sie beschreiben, was SPR macht?

SPR ist ein Beratungsunternehmen für digitale Technologie mit Sitz im Raum Chicago, das Technologieprojekte für eine Reihe von Kunden durchführt, von Fortune-1000-Unternehmen bis hin zu lokalen Startups. Wir erstellen durchgängige digitale Erlebnisse mit einer Reihe von Technologiefunktionen, von der Entwicklung kundenspezifischer Software, Benutzererfahrung, Daten und Cloud-Infrastruktur bis hin zu DevOps-Coaching, Softwaretests und Projektmanagement.

 

Was sind einige Ihrer Aufgaben bei SPR?

Als Hauptarchitekt ist es meine Hauptaufgabe, die Lösungsbereitstellung für Kunden voranzutreiben und die Architektur und Entwicklung von Projekten zu leiten. Dazu gehört oft auch die Rolle des Product Owners, weil es wichtig ist, die Art und Weise, wie Produkte aus einer praktischen Perspektive hergestellt werden, nachvollziehen zu können Es geht stark darum, wie die Arbeit priorisiert werden sollte, insbesondere wenn man von Grund auf neu baut. Ich werde auch in Gespräche mit potenziellen Kunden einbezogen, wenn mein Fachwissen benötigt wird, und das Unternehmen hat mich kürzlich darum gebeten, eine fortlaufende Reihe von Sitzungen mit anderen Architekten in der Datenpraxis zu starten, um Kundenprojekte, Nebenprojekte und meine Kollegen zu besprechen Ich habe etwas getan, um mit der Technologie auf dem Laufenden zu bleiben, ähnlich wie ich es bei einer früheren Beratungsfirma getan hatte, obwohl die internen Treffen dieser anderen Firma sozusagen ihre gesamte Technologiepraxis betrafen und nicht speziell die Datenarbeit.

Den größten Teil meiner Karriere habe ich mich auf die Open-Source-Entwicklung mit Java spezialisiert und dabei immer mehr Datenarbeit geleistet. Zusätzlich zu diesen beiden Spezialisierungen beschäftige ich mich auch mit dem, was meine Kollegen und ich inzwischen als „praktische“ oder „pragmatische“ Unternehmensarchitektur bezeichnen, was bedeutet, Architekturaufgaben im Kontext dessen auszuführen, was gebaut werden soll, und es vielmehr tatsächlich aufzubauen als nur darüber zu reden oder Diagramme darüber zu zeichnen, wobei man sich natürlich darüber im Klaren ist, dass diese anderen Aufgaben auch wichtig sind.

Meiner Ansicht nach überschneiden sich diese drei Spezialisierungen und schließen sich nicht gegenseitig aus. Ich habe Führungskräften in den letzten Jahren erklärt, dass die Grenze, die traditionell von der Technologiebranche zwischen Softwareentwicklung und Datenarbeit gezogen wurde, nicht mehr klar definiert ist, teils weil sich die Tools zwischen diesen beiden Bereichen angenähert haben, teils weil Aufgrund dieser Konvergenz ist die Datenarbeit selbst größtenteils zu einer Softwareentwicklung geworden. Da traditionelle Datenpraktiker jedoch normalerweise keinen Hintergrund in der Softwareentwicklung haben und umgekehrt, helfe ich dabei, diese Lücke zu schließen.

 

Was ist ein interessantes Projekt, an dem Sie derzeit mit SPR arbeiten?

Erst kürzlich habe ich das veröffentlicht erster Beitrag in einer mehrteiligen Fallstudienreihe über die zuvor erwähnte Datenplattform, die mein Team und ich im vergangenen Jahr für den CIO eines in Chicago ansässigen globalen Beratungsunternehmens von Grund auf in AWS implementiert haben. Diese Plattform besteht aus Datenpipelines, Data Lake, kanonischen Datenmodellen, Visualisierungen und Modellen für maschinelles Lernen, die von Unternehmensabteilungen, Praxen und Endkunden des Kunden genutzt werden können. Während die Kernplattform von der vom CIO geleiteten IT-Organisation des Unternehmens aufgebaut werden sollte, bestand das Ziel darin, diese Plattform auch von anderen Organisationen außerhalb der Unternehmens-IT zu nutzen, um Datenbestände und Datenanalysen im gesamten Unternehmen mithilfe einer gemeinsamen Architektur zu zentralisieren. Darauf aufbauend, um die Anwendungsfallanforderungen jeder Organisation zu erfüllen.

Wie bei vielen etablierten Firmen war die Verwendung von Microsoft Excel an der Tagesordnung, wobei Tabellenkalkulationen häufig innerhalb und zwischen Organisationen sowie zwischen der Firma und externen Kunden verteilt wurden. Darüber hinaus waren Geschäftsbereiche und Beratungspraxen isoliert und nutzten jeweils unterschiedliche Prozesse und Tools. Neben der Zentralisierung von Datenbeständen und Datenanalysen bestand ein weiteres Ziel darin, das Konzept des Dateneigentums umzusetzen und den Datenaustausch zwischen Organisationen auf sichere und konsistente Weise zu ermöglichen.

 

Gibt es noch etwas, das Sie über Open Source, SPR oder ein anderes Projekt, an dem Sie arbeiten, mitteilen möchten?  

Ein weiteres Projekt (lesen Sie darüber wenn sie hier klicken und wenn sie hier klicken), die ich kürzlich leitete, umfasste die erfolgreiche Implementierung der Databricks Unified Analytics Platform und die Migration der Ausführung von Modellen für maschinelles Lernen darauf von Azure HDInsight, einer Hadoop-Distribution, für den Leiter der Datentechnik eines großen Versicherers.

Alle diese migrierten Modelle sollten den Grad der Verbraucherakzeptanz vorhersagen, der für verschiedene Versicherungsprodukte zu erwarten ist. Einige wurden einige Jahre zuvor von SAS migriert, als das Unternehmen zu HDInsight überging. Die größte Herausforderung war die schlechte Datenqualität, aber zu den weiteren Herausforderungen gehörten der Mangel an umfassender Versionierung, Stammeswissen und unvollständige Dokumentation sowie eine unausgereifte Databricks-Dokumentation und -Unterstützung in Bezug auf die damalige R-Nutzung (die Azure-Implementierung von Databricks war gerade erst allgemein verfügbar gemacht worden). einige Monate vor diesem Projekt).

Um diese zentralen Herausforderungen anzugehen, habe ich im Anschluss an unsere Implementierungsarbeit Empfehlungen zu Automatisierung, Konfiguration und Versionierung, Trennung von Datenbelangen, Dokumentation und der erforderlichen Abstimmung zwischen den Daten-, Plattform- und Modellierungsteams abgegeben. Unsere Arbeit überzeugte einen zunächst sehr skeptischen Chief Data Scientist davon, dass Databricks der richtige Weg ist, mit dem erklärten Ziel, nach unserem Weggang die verbleibenden Modelle so schnell wie möglich auf Databricks zu migrieren.

Dies war ein faszinierendes Interview, das viele Themen berührte. Ich habe das Gefühl, viel über Open Source gelernt zu haben. Leser, die mehr erfahren möchten, können die besuchen SPR Unternehmenswebsite bzw Erik Gfessers Website.

Ein Gründungspartner von unite.AI und Mitglied der Forbes Technology Council, Antoine ist ein Futurist der sich leidenschaftlich für die Zukunft von KI und Robotik interessiert.

Er ist auch der Gründer von Wertpapiere.io, eine Website, die sich auf Investitionen in bahnbrechende Technologien konzentriert.