In den letzten Tagen ist quasi nebenbei wieder etwas mehr Material auf die Website gekommen. Neben dem Überblick aus der Vogelperspektive gibt es jetzt Information zu der prinzipiellen modellbasierten Vorgehensweise von OpenSAGA. Ich habe soeben einen ersten Abschnitt zu der Theorie hinter den Modellen(wenn man das so nennen will, unten mehr) fertig geschrieben, Sven hat Informationen zum Generator und zu Barrierefreiheit ergänzt.
Beiträge aus Januar 2010.
Schlagworte: Dokumentation, Modelle, OpenSAGA
Man muss sich auch über die kleinen Dinge freuen… im Moment sind wir zwar noch sehr beschäftigt damit, einige Projekte abzuschließen, aber immerhin haben wir zwischendurch schon mal einen ersten Überblick über den grundlegenden Plattform-Ansatz von OpenSAGA live geschaltet. Die Menge der “folgt in Kürze”-Einträge ist zugegebenermaßen noch recht… hoch… aber das wird in nächster Zeit.
Wir haben den 01.05. als offiziellen Termin für die Release-Party der Version 1.0 von OpenSAGA definiert. Mit diesem Thema haben wir auch lange gerungen, da “Release early, release often” natürlich für Open Source eine Menge Sinn macht. Daher würde ich heute gerne einige Überlegungen beschreiben, die uns auf dem Weg über ein oder mehrere Preview Releases zur Version 1.0 führen werden. Ich würde mich über Feedback freuen, da OpenSAGA unser erstes Open-Source-Projekt als Firma ist und Erfahrungswerte anderer dabei natürlich besonders wertvoll sind. Was sind also die Dinge, die wir für essentiell halten, bevor es das erste Preview-Release gibt?
OpenSAGA-basierte Namenskonventionen
Bislang war OpenSAGA ein reines Inhouse-Projekt. Insbesondere eins mit einem anderen Arbeitstitel, was eine Menge interner Namenskonventionen nach sich zieht. Diese wollen wir auf jeden Fall vor dem ersten Prerelease bereinigen (d.h. Packages umbenennen, eine Reihe von Klassen, Methoden, Feldern, jede Menge javadoc, usw. anpassen – triviale aber aufwändige Arbeit). Außerdem müssen wir unser Buildsystem so umbauen, dass es nicht nur auf unsere internen Bedürfnisse passt, sondern auch für den Rest der Welt Sinn macht.
Rechtliche Fragen
Bei einem Inhouse-Projekt geht man ja immer etwas lockerer mit der formalen Verwaltung rechtlicher Aspekte um. Wir tun nichts Verbotenes, aber wir müssen die ganzen Lizenzen der Projekte, die wir referenzieren, noch sinnvoll zusammenkopieren und strukturieren. Wir müssen unsere eigene duale Lizenz (GPL v3 und eine proprietäre) noch endgültig festlegen. Auch mit unseren bisherigen Partnern müssen natürlich gewisse organisatorische Fragen geklärt werden.
Dokumentation
Immer ein heikles Thema. Wir wären gerne so gut wie Spring, aber das sind noch einige Meter. Bisher haben wir überwiegend Inhouse-Schulungen zu OpenSAGA gemacht, wir brauchen noch einige grundlegende Tutorials, usw. Perfekt wird sowas nie, etwas besser muss es aber noch werden 
Qualitätsfragen
Wir arbeiten hinter den Kulissen bereits mit einer Reihe von Partnern zu OpenSAGA zusammen, die in den nächsten Wochen und Monaten auch zunehmend auf dieser Website präsent werden. Wir suchen aber noch viele weitere Partner und mein Kalender hat sich nach der initialen OpenSAGA-Ankündigung bereits dramatisch mit Terminen gefüllt. Wir wollen uns daher ein etwas breiteres und repräsentatives Feedback von diesen Gesprächspartnern holen, dass wir ggf. auch gleich bei den ersten Releases berücksichtigen wollen. Zudem werden wir in Kürze unseren wissenschaftlichen Beirat vorstellen, der uns berät.
Infrastrukturaufbau
Wir haben OpenSAGA immer als Community formuliert und eine Community braucht zumindest etwas Infrastruktur. Wir versuchen dabei bereits, maximal pragmatisch vorzugehen. Beispiel: Ursprünglich wollten wir die OpenSAGA-Website mit OpenSAGA selbst bauen (was irgendwie auch Sinn macht), dann haben wir uns aber klar gemacht, dass wir dann eine Menge Zeit verlieren würden, denn auch wenn das technisch möglich ist, bietet OpenSAGA heute kein so vollwertiges Wiki oder Blog oder… wie andere Lösungen, die bereits da sind. Denn OpenSAGA ist nur eine mögliche Plattform für solche Lösungen. Also haben wir uns für den Start mit WordPress entschieden, um so schnell wie möglich sichtbar zu sein und Material zu haben, über das man mit potenziellen Partnern und Interessenten zu reden. Bevor wir ein Release (und sei es nur ein Preview-Release) machen, brauchen wir aber etwas mehr Infrastruktur, um dann auch mit Feedback umgehen zu müssen. D.h. wir brauchen m.E. noch ein Ticketsystem (z.B. JIRA), eine Forensoftware und evtl. ein Wiki. Und dann brauchen wir vermutlich auch noch einen anderen Server, auf den wir umziehen wollen.
Was soll ich sagen? Wir arbeiten mit Hochdruck dran, aber es braucht halt noch ein paar Augenblicke.
Insgesamt also eine Reihe von Themen, die alle nicht kritisch sind, aber jedes für sich etwas Zeit brauchen. Daher also der 01.05. als Termin, zumals das gut mit dem e-Government-Day auf der JAX zusammenfällt, den wir organisieren und sponsoren. Wir sind aber guter Dinge, im März die ersten Previews zum Download bereit zu haben.
In diesem Sinne bis zum nächsten Update der Website!
Schlagworte: Dokumentation, Infrastruktur, Lizenz, OpenSAGA, Release, Roadmap
Zunächst einmal ein frohes neues und erfolgreiches Jahr 2010 an alle!
Da wir mit OpenSAGA in 2010 richtig Gas geben werden, würde ich den Jahresanfang gerne nutzen wollen, um das OpenSAGA-Kernteam vorzustellen, das zukünftig hier im Blog über verschiedenste Aspekte von OpenSAGA berichten wird und natürlich auch gerne für Fragen zur Verfügung steht. Dies sind:
Thomas Biskup (also ich, QuinScape GmbH) bin der Project Lead und Principal Architect hinter der OpenSAGA als Gesamtsystem. Ich entwickle auch mit und bewege mich dabei meist im Backend-Bereich von OpenSAGA – überwiegend Meta-Features wie Scripting-Support, Scoping von Daten, Agenten, Aktionsverarbeitung, Persistenz, usw. Außerdem beschäftige ich mich mit der externen Darstellung von OpenSAGA, betreue Partner und Projekte und kümmere mich um die Kommunikation. Bei Fragen und Anregungen bin ich unter thomas.biskup@quinscape.de zu erreichen. Bei Xing moderiere ich passenderweise das SAGA-Forum. Ansonsten interessiere ich mich für alles rund um Java, Spring, moderne und schlanke Architekturen, Portale und Webapplikationen und eine anforderungsgetriebene Entwicklung von Systemen.
Sven Helmberger (QuinScape GmbH) ist Principal Web Architect bei QuinScape und verantwortlich für den Web-Layer bei OpenSAGA. Er verantwortet alles rund um JSF, JavaScript und die vielen coolen Features von OpenSAGA hinsichtlich Barrierefreiheit, der automatischen Unterstützung JavaScript-loser Umgebungen, unser automatisiertes CSS-Bundling, die automatische Generierung von CSS-Sprites, usw. pp. Sven ist außerdem Hauptentwickler von jcouchdb, einem Java-5-CouchDB-Treiber, sowie von svenson, einer Java-5-JSON-Library und boticelli, einem Java-IRC-Bot mit Twitter-Integration.
Jochen Terstiege (QuinScape GmbH) ist Senior Architect bei QuinScape und arbeitet vornehmlich im Backendbereich von OpenSAGA. Er kümmert sich insbesondere um Webflow, Hibernate, sämtliche Integrationsschnittstellen, die Performance, u.v.a.m.
Alexander Kandelberg (QuinScape GmbH) verantwortet die Entwicklung des OpenSAGA-Eclipse-Plugins, dass vielfältige Unterstützung bei der Entwicklung von OpenSAGA-Modellen bietet. Zudem arbeitet er an der Standardisierung der XML-Schemata und der damit verbundenen Architekturentscheidungen mit.
Ulf Müller-Baumgart (QuinScape GmbH) ist vornehmlich mit der Qualitätssicherung von OpenSAGA beschäftigt. Er arbeitet an den Selenium-basierten Automatisierung unserer Integrationstests und findet die Fehler, die wir anderen übersehen.
Sebastian Bereda (QuinScape GmbH) unterstützt uns an vielen Stellen in der Programmierung und Dokumentation, hat maßgeblich an den existierenden Web-Service- und REST-Schnittstellen mitgewirkt und ist ein stetiger Sparringspartner bei der Diskussion von Entwurfs- und Implementierungsentscheidungen.
Christian Schneider (BALVI GmbH) ist aufgrund seiner langjährigen Java-Kenntnissen als Entwicklungsleiter verantwortlich für das BALVI Web Framework, welches auf OpenSAGA basiert, und setzt Projekte auf dieser Basis um. Er realisierte die ersten beiden Produktintegrationen für Anwendungsszenarien im Umfeld des behördlichen Verbraucherschutzes und der Lebensmittelüberwachung. Zudem unterstützt er die Grundlagenentwicklung bei der praktischen Ausrichtung des Frameworks hinsichtlich der möglichst effizienten Umsetzung von Anwendungsfällen und Projekterfahrungen aus dem Umfeld von Bundes- und Landesbehörden.
Christopher Klewes (BALVI GmbH) setzt ebenfalls Projekte auf Basis von OpenSAGA und der BALVI-Web-Plattform um und unterstützt uns bei der Fehlersuche, Optimierung und Erweiterung von OpenSAGA an vielen Stellen, bei denen sich in Projekten interessante neue Features oder Optimierungspotenziale ergeben.
Christian Schneider (BALVI GmbH) ist seinen langjährigen Java-Kenntnissen als Entwicklungsleiter verantwortlich für das BALVI Web Framework, welches auf OpenSAGA basiert, und setzt Projekte auf dieser Basis um. Er realisierte die ersten beiden Produktintegrationen für Anwendungsszenarien im Umfeld des behördlichen Verbraucherschutzes und der Lebensmittelüberwachung. Zudem unterstützt er die Grundlagenentwicklung bei der praktischen Ausrichtung des Frameworks hinsichtlich der möglichst effizienten Umsetzung von Anwendungsfällen und Projekterfahrungen aus dem Umfeld von Bundes- und Landesbehörden.
